gnodet commented on issue #13084:
URL: https://github.com/apache/maven/issues/13084#issuecomment-5616548419

   ## Investigation
   
   This reproduces with the latest Resolver 2.0.23-SNAPSHOT (post-2.0.22), not 
with the released 2.0.22.
   
   ### Dependency chain for `resteasy-client:7.0.0.Final`
   
   The effective model depends on a parent POM chain:
   ```
   resteasy-client:7.0.0.Final
     → parent: resteasy-jaxrs-all:7.0.0.Final
         → dependencyManagement imports BOM: 
resteasy-dependencies:${project.version} = 7.0.0.Final
             → defines versions for jboss-logging, httpclient, commons-codec, 
jetty-client, etc.
   ```
   
   When the BOM import fails (the `resteasy-dependencies:7.0.0.Final` POM is 
not resolved), versions are never injected into `resteasy-client`'s 
dependencies. The effective model validator then reports `ERROR: 
'dependencies.dependency.version' ... is missing` for each of the 9 unversioned 
deps → `ModelBuildingException`.
   
   ### Likely root cause: commit `339161be` in maven-resolver
   
   The commit ["fix: earn trust labels through verification and bind tracking 
to URL" (#2080)](https://github.com/apache/maven-resolver/pull/2080) 
(post-2.0.22, targeting 2.0.23) introduces several changes to 
`EnhancedLocalRepositoryManager` and `DefaultArtifactResolver`:
   
   1. **`existenceCheckRelabel` now defaults to `false`**: previously, if an 
artifact was present in the local repo but not tracked for the current 
repository, a bare existence check would re-label it as available. Now it 
forces a re-download instead. This means POM artifacts in the parent/BOM chain 
(like `resteasy-dependencies:7.0.0.Final`) may fail to resolve if they are not 
tracked for the current session's repositories.
   
   2. **URL-qualified tracking keys** (`nid_hurl` format replaces the old `nid` 
format): existing tracking entries written as `central=` are now looked up as 
`central-<sha1url>=`. With `legacyTrackingFallback=true` (default) this should 
still work via fallback, but the interaction with `existenceCheckRelabel=false` 
may cause the issue.
   
   3. **`verifyRealPath=true` by default**: `hasFaithfulRealPath()` calls 
`path.toRealPath()` — if the local repository base path involves symlinks this 
can cause physically-present POMs to be treated as "not found", forcing a 
re-download that may fail.
   
   The critical path is: `DefaultArtifactDescriptorReader` → 
`DefaultModelBuilder.importDependencyManagement()` → 
`DefaultModelResolver.resolveModel()` → `resolver.resolveArtifact()`. If that 
resolution fails, the BOM import is silently skipped, deps have no versions, 
and effective model validation fails.
   
   ### Suggested investigation
   
   1. Run with `-X` and look for the resolution of 
`org.jboss.resteasy:resteasy-dependencies:7.0.0.Final` POM during model building
   2. Bisect resolver commits between 2.0.22 and current snapshot — `339161be` 
is the prime suspect
   3. Quick workarounds to test:
      - `-Daether.enhancedLocalRepository.verifyRealPath=false`
      - `-Daether.enhancedLocalRepository.existenceCheckRelabel=true` (restores 
old behavior)


-- 
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]

Reply via email to