gnodet commented on issue #12303:
URL: https://github.com/apache/maven/issues/12303#issuecomment-4738651977
## Root Cause Analysis
### The setup
`bigtop-manager` uses CI-friendly versions — the root POM has:
```xml
<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_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
