[MNG-6772] Super POM overwrites remapped central repository in nested dependencyManagement import POMs

• Type: Bug
• Status: Reopened
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 3.6.2
• Fix Version/s: 4.0.x-candidate
• Component/s: Artifacts and Repositories, POM
• Labels: must-be-in-4.0.0-alpha-2
• Assignee: Unassigned
• Reporter: Eddie Wiegers
• Created: 01/Oct/19 19:55
• Updated: 02/Mar/22 20:17

Description

My projects define a repository with <id>central</id>, which is meant to specifically override the entry in the Super POM. This is specifically what JFrog Artifactory recommends doing, and seems valid in situations where the real Maven Central may be unreachable.

 

The override takes precedence almost all of the time. However, there is at least one scenario where this is not the case, and that is when importing a POM that in turn imports another POM.

 

Digging into the code, it appears the reason this happens is because the DefaultModelBuilder overwrites repositories after interpolation is complete:

https://github.com/apache/maven/blob/53f04f03e3e58c75dcc791d557758357a6ec7983/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L411

 

From what I can tell, this is done with the intention of overwriting repositories that were added to the local resolver prior to interpolation with the interpolated version. Due to the way the DefaultModelResolver works, an unintended side effect is that the central repository from the Super POM is added once after each interpolation. The first time the repository is added, it is added to the repositoryIds but doesn't actually remove the original repository. The second time it is added is when the original repository will be replaced. Currently, the repositoryIds are preserved in the ModelResolver when resolving import POMs, leading to the behavior I am seeing where the second nested import POM ends up being where the failure occurs.

 

I am planning on submitting a PR to clone the ModelResolver in a way that resets the repositoryIds prior to import POMs being resolved, since they are separate artifact builds. That seems like the most consistent fix to me that covers cases outside of the the Super POM's central definition.

 

Workarounds:

The current workaround is to use a repository ID other than central for my Artifactory repository, which isn't ideal since it leaves the potential for long timeouts to occur on the real central when an artifact can't be resolved from my Artifactory repository.

 

Mirrors are not an ideal workaround since getting them in place on all possible build environments isn't trivial.

 

When looking at the code I noticed RepositorySystemSession#isIgnoreArtifactDescriptorRepositories() being checked in various places, which seems like it would also act as a potential workaround, but I don't see a way to enable this value via MavenCLI or properties of any kind. It seems like this value aligns well with what Artifactory is already trying to enforce, so it would make sense to enable this in projects that intend to exclusively use Artifactory. Is there a supported way to set this value outside of constructing a Maven build in code?

Issue Links

• causes: MNG-6397 Maven Transitive Dependency Resolution Does Not Respect Repository Definition in pom.xml
• duplicates: MNG-5781 resolution of nested import scoped dependencies causes maven to reach out to external central repo
• is duplicated by: MNG-6283 [regression] resolution of nested import-scoped transitive dependencies ignores repositories overwriting 'central'
• relates to: MNG-4347 import-scoped dependencies of direct dependencies are not resolved using profile modifications from settings.xml
• relates to: MRESOLVER-168 add DEBUG message when downloading an artifact from repositories
• relates to: MNG-7094 Assure in an IT that reactor repository definitions are not used when Model Builder downloads dependencies with scope import
• links to: GitHub Pull Request #49
• links to: GitHub Pull Request #289