[
https://issues.apache.org/jira/browse/MNG-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17243515#comment-17243515
]
Eddie Wiegers commented on MNG-6772:
------------------------------------
[~michael-o]
Fair enough, I concede. I still consider overriding {{central}} in the POM
instead of settings.xml a design choice rather than a loop hole based on the
repository order you linked. It should be valid to overwrite at any layer that
has higher precedence than the Super POM, and we chose to overwrite in the
Local POM because that override lives with the project in source control so
seems more portable than trying to make sure settings.xml is set up properly on
every machine that performs builds.
If this is not an intended workflow, perhaps we'll just remove the overrides
from the POM completely so that builds fail to resolve even our internal parent
POM which will fail fast and hopefully clue developers in that they are missing
crucial configuration instead of having things mostly work but fail in some
edge cases.
Because JFrog's documentation states:
{quote}To do so, you need to insert the following into your parent POM or
settings.xml (under an active profile)
{quote}
I would recommend reaching out to them and having them update the documentation
to only mention the settings.xml, as I have to imagine there are many
Artifactory users that have configured their POMs this way and will break if
Maven stops allowing it.
Thanks for engaging in this discussion, and perhaps I'll be able to contribute
something more valuable in the future.
> 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
> Assignee: Sylwester Lachiewicz
> Priority: Major
> Fix For: wontfix-candidate, 4.0.0, 4.0.0-alpha-1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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)
