maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eddie Wiegers (Jira)" <>
Subject [jira] [Commented] (MNG-6772) Super POM overwrites remapped central repository in nested import POMs
Date Fri, 01 Nov 2019 22:55:00 GMT


Eddie Wiegers commented on MNG-6772:

Sure, but in this situation the project I'm trying to build is the child (which is overriding
central from the Super POM), and everything else during that build can be considered a "child"
scope of that project (including resolution of its parent POM and any import POMs). I believe
Maven already behaves this way, treating the repositories from the project being built as
the "dominant" repositories throughout the build process. It is just the single case that
I've described that seems to behave differently, which is why it seems like a bug to me.

> Super POM overwrites remapped central repository in nested import POMs
> ----------------------------------------------------------------------
>                 Key: MNG-6772
>                 URL:
>             Project: Maven
>          Issue Type: Bug
>          Components: Artifacts and Repositories, POM
>    Affects Versions: 3.6.2
>            Reporter: Eddie Wiegers
>            Priority: Major
>          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
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:
> []
> 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
> 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

View raw message