Eddie Wiegers created MNG-6772:
----------------------------------

             Summary: Super POM overwrites remapped central repository in 
nested import POMs
                 Key: MNG-6772
                 URL: https://issues.apache.org/jira/browse/MNG-6772
             Project: Maven
          Issue Type: Bug
          Components: Artifacts and Repositories, POM
    Affects Versions: 3.6.2
            Reporter: Eddie Wiegers


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|[https://www.jfrog.com/confluence/display/RTF/Maven+Repository#MavenRepository-ManuallyOverridingtheBuilt-inRepositories]]
 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?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to