CI-friendly ${revision} not interpolated when used by maven-remote-resources-plugin

[gnodet]

Description

When building bigtop-manager with Maven from the maven-4.0.x branch, the maven-remote-resources-plugin:3.0.0 attempts to resolve the project's own artifact using the literal string ${revision} instead of the interpolated version value.

Error

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-remote-resources-plugin:3.0.0:process
  (process-resource-bundles) on project bigtop-manager-stack-bigtop:
  Execution process-resource-bundles of goal
  org.apache.maven.plugins:maven-remote-resources-plugin:3.0.0:process failed:
  Invalid Version Range Request: org.apache.bigtop:bigtop-manager:pom:${revision}

The ${revision} placeholder should have been interpolated to the actual version before the plugin tried to resolve it.

Context

The project uses CI-friendly versions (${revision}) as documented in Maven's CI-friendly documentation. This works correctly with Maven 3.x but fails with Maven 4.x.

Reproducer

git clone https://github.com/apache/bigtop-manager.git
cd bigtop-manager
mvn -B -e clean package -DskipTests

Environment

• Maven: built from maven-4.0.x branch (bootstrapped with 4.0.0-rc-5)
• JDK: 17 (Temurin)

Context

Found during Maven 4 compatibility testing.

Claude Code on behalf of Guillaume Nodet

[gnodet]

Root Cause Analysis

The setup

bigtop-manager uses CI-friendly versions — the root POM has:

<version>${revision}</version>
<properties>
    <revision>1.2.0-SNAPSHOT</revision>
</properties>

The maven-remote-resources-plugin:3.0.0 is inherited from the Apache parent POM and runs on every module.

The failure chain

1. maven-remote-resources-plugin uses the legacy artifact resolver (DefaultLegacyArtifactCollector → MavenMetadataSource.retrieveRelocatedProject) to walk the project's dependency graph
2. This legacy path calls DefaultProjectBuilder.build() to build the model of each dependency — including the root parent org.apache.bigtop:bigtop-manager:pom:${revision}
3. When building the parent model, the legacy resolver creates an artifact with the literal version string ${revision} (not interpolated)
4. Maven 4's MavenValidator.validateArtifact() catches this and throws: "Not fully interpolated artifact org.apache.bigtop:bigtop-manager:pom:${revision}"
5. This propagates as IllegalArgumentException: Invalid Version Range Request

Why Maven 3 worked

Maven 3 did not have MavenValidator — there was no validation rejecting artifacts with ${...} placeholders in coordinates. The legacy resolver would pass through the literal ${revision} and it would either get resolved during model building or simply work because Maven 3's artifact system was more lenient about version strings.

Root cause

The legacy compatibility code path (maven-compat module) doesn't properly interpolate CI-friendly properties (${revision}, ${sha1}, ${changelist}) before creating artifacts. The MavenValidator (new in Maven 4) then rightfully rejects the uninterpolated artifact.

This is essentially the same class of issue as #12305 — the legacy resolver creates artifacts or dependencies with unresolved ${...} expressions, and Maven 4's stricter validation catches them.

Fix direction

Two possible approaches:

1. In the legacy resolver path: ensure CI-friendly properties are interpolated before artifact creation in MavenMetadataSource.retrieveRelocatedProject and DefaultProjectDependenciesResolver
2. In MavenValidator: make the validation aware that CI-friendly properties (revision, sha1, changelist) are special and should not trigger rejection — though this is less clean

The proper fix is (1): the model building in the legacy path should resolve CI-friendly properties the same way the new model builder does.

Claude Code on behalf of Guillaume Nodet