Problem:
Changes to ${revision} in profiles do not propagate to the final project version in Maven 4. This regression from Maven 3 occurs because CI-friendly version processing happens before profile activation, so profile properties are not available during version resolution.

Example of the issue:

<version>${revision}</version>
<properties>
  <baseVersion>0.2.0</baseVersion>
  <revision>${baseVersion}+dev</revision>
</properties>
<profiles>
  <profile>
    <id>release</id>
    <properties>
      <revision>${baseVersion}</revision> <!-- This was ignored -->
    </properties>
  </profile>
</profiles>

• mvn clean → version: 0.2.0+dev ✅
• mvn clean -Prelease → version: 0.2.0+dev ❌ (should be 0.2.0)

Root Cause:
In Maven 4, the model building sequence is:

1. CI-friendly version processing (uses base properties only)
2. Profile activation and injection
3. Model interpolation

This means profile properties are not available when CI-friendly versions are resolved.

Solution:
Implement enhanced property resolution that performs lightweight profile activation during CI-friendly version processing. This ensures profile properties are available for both version resolution and repository URL interpolation.

Key Changes

1. Enhanced Property Resolution (DefaultModelBuilder.java)

• getEnhancedProperties(Model model): New method that performs profile-aware property resolution
• getPropertiesWithProfiles(Model model, Map<String, String> baseProperties): Performs lightweight profile activation
• Unified processing: Both CI-friendly versions and repository URLs use the same profile-aware properties

2. Directory Properties Integration

• Moved directory properties (basedir, project.basedir, project.rootDirectory) to be available during profile activation
• Enables file-based profile activation that depends on directory properties
• Ensures consistent property resolution order

3. Comprehensive Test Coverage

• Unit tests: DefaultModelBuilderTest.java with 3 new test methods
• Integration test: MavenITmng11196CIFriendlyProfilesTest.java reproducing the exact GitHub issue
• Test resources: Multiple POM files covering various scenarios

Benefits

1. Fixes the regression: Profile-based CI-friendly versions now work as in Maven 3
2. Backward compatible: All existing CI-friendly functionality continues to work
3. Enhanced repository URLs: Repository URL interpolation now also works with profile properties
4. Better profile activation: Directory properties are available during profile activation
5. Error resilient: Falls back to base properties if profile activation fails

Additional Use Cases Enabled

Repository URLs with Profile Properties

<profiles>
  <profile>
    <id>development</id>
    <properties>
      <repo.base.url>http://dev-nexus.company.com</repo.base.url>
    </properties>
  </profile>
</profiles>
<repositories>
  <repository>
    <id>company-repo</id>
    <url>${repo.base.url}/repository/maven-public/</url>
  </repository>
</repositories>

File-based Profile Activation with Directory Properties

<profiles>
  <profile>
    <id>docker-build</id>
    <activation>
      <file>
        <exists>${project.basedir}/Dockerfile</exists>
      </file>
    </activation>
    <properties>
      <revision>${baseVersion}-docker</revision>
    </properties>
  </profile>
</profiles>

Testing

The implementation includes comprehensive test coverage:

1. Unit Tests:

   • testCiFriendlyVersionWithProfiles(): Basic profile-based CI-friendly versions
   • testRepositoryUrlInterpolationWithProfiles(): Repository URL interpolation with profiles
   • testDirectoryPropertiesInProfilesAndRepositories(): Directory properties in profiles

2. Integration Tests:

   • MavenITmng11196CIFriendlyProfilesTest: Reproduces the exact GitHub issue scenario
   • Tests both default behavior and profile-activated behavior

Verification

After the fix:

• mvn clean → version: 0.2.0+dev ✅
• mvn clean -Prelease → version: 0.2.0 ✅

Closes #11196

Pull Request opened by Augment Code with guidance from the PR author