[jira] [Comment Edited] (MNG-6772) Super POM overwrites remapped central repository in nested import POMs
[
https://issues.apache.org/jira/browse/MNG-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17265893#comment-17265893
]
Michael Osipov edited comment on MNG-6772 at 1/15/21, 10:54 AM:
[~rfscholte], will you also revert the commit and IT?
was (Author: michael-o):
Robert, will you also revert the commit and IT?
> 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
> Time Spent: 20m
> Remaining Estimate: 0h
>
> My projects define a repository with {{central,}} 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)
[jira] [Comment Edited] (MNG-6772) Super POM overwrites remapped central repository in nested import POMs
[
https://issues.apache.org/jira/browse/MNG-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17244214#comment-17244214
]
Michael Osipov edited comment on MNG-6772 at 12/4/20, 6:55 PM:
---
[~ewiegs4], I asked JFrog via Twitter DM to engage with the Maven community. A
downside of commercial endeavors is that that there is virtually no reasonable
way to get in touch unless you want to buy something or have a support
contract. My turnaround time on JIRA is way faster then getting anything
reasonable from them. I painfully know fom Oracle Support spite paying millions
of euros in support each year.
was (Author: michael-o):
[~ewiegs4], I asked JFrog via Twitter DM to engage with the Maven community. A
downside of commercial endeavors is that that there is virtually no reasonable
way to get in touch unless you want to buy something or have a support
contract. My turnaround time on JIRA is way faster then getting anything
reasonable from them. I mainfully know fom Oracle Support spite paying millions
of euros in support each year.
> 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 {{central,}} 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)
[jira] [Comment Edited] (MNG-6772) Super POM overwrites remapped central repository in nested import POMs
[
https://issues.apache.org/jira/browse/MNG-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17244214#comment-17244214
]
Michael Osipov edited comment on MNG-6772 at 12/4/20, 6:42 PM:
---
[~ewiegs4], I asked JFrog via Twitter DM to engage with the Maven community. A
downside of commercial endeavors is that that there is virtually no reasonable
way to get in touch unless you want to buy something or have a support
contract. My turnaround time on JIRA is way faster then getting anything
reasonable from them. I mainfully know fom Oracle Support spite paying millions
of euros in support each year.
was (Author: michael-o):
[~ewiegs4], I asked JFrog via Twitter DM to engage with the Maven community. A
downside of commercial endeavors is that that there virtually no reasonable way
to get in touch unless you want to buy something or have a support contract. My
turnaround time on JIRA is way faster then getting anything reasonable from
them.
> 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 {{central,}} 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)
[jira] [Comment Edited] (MNG-6772) Super POM overwrites remapped central repository in nested import POMs
[
https://issues.apache.org/jira/browse/MNG-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242724#comment-17242724
]
Michael Osipov edited comment on MNG-6772 at 12/2/20, 9:05 PM:
---
[~MattNelson], please see
https://maven.apache.org/guides/mini/guide-multiple-repositories.html#repository-order.
This is the expected behavior when MNG-6114 is fixed. As far as import POMs
are concerned, I do not rely know regarding repos. I cannot give a qualified
answer.
The ideal case is that no POM redefines a "parent" repository. I'd like to see
an IT where an import POM deliberately modifies a repo definition from your
project's POM with a different URL, but with the same id. We'd definitvely need
to analyze this behavior and add it to the repo order documentation since it
causes a lot of fuzz and confusion in the community.
The upshot is: never override a repo which is out of your control in your POM.
was (Author: michael-o):
[~MattNelson], please see
https://maven.apache.org/guides/mini/guide-multiple-repositories.html#repository-order.
This is the expected behavior when MNG-6114 is fixed. As far as import POMs
are concerned, I do not rely know regarding repos. I cannot give a qualified
answer.
The ideal case is that no POM redefines a "parent" repository. I'd like to see
an IT where an import POM deliberately modifies a repo definition from your
project's POM with a different URL, but with the same id. We'd definitvely need
to analyze this behavior and add it to the repo order documentation since it
causes a lot of fuzz and confusion in the community.
> 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 {{central,}} 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 pote
[jira] [Comment Edited] (MNG-6772) Super POM overwrites remapped central repository in nested import POMs
[ https://issues.apache.org/jira/browse/MNG-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242721#comment-17242721 ] Michael Osipov edited comment on MNG-6772 at 12/2/20, 8:59 PM: --- [~ewiegs4] bq. I believe settings.xml always wins over POM (even when directly declared in the project being built). That's why I fully expect moving Maven central from the super POM (lowest priority) to the default global settings.xml (near-highest priority) to break the setup we have where we override central in the POM. I personally don't like this change as I believe it makes builds less portable, but I know I'm not going to win that argument so won't go any further on that point. Central has been embedded into Core for historical reasons. Since many public mirrors are availabe and corporate users like me sit behind Nexus or Artifactory it does not make sense to have this hardcoded, it needs to be swappable. At the end Mavn should not care about Central, it just should know where to download artifacts. It could be even S3 buckets if the structure allows that. bq. Going back to this particular change, modifying the settings.xml is basically telling Maven you want it to behave differently on that machine and the settings usually win over what's in the pom, so I'm sure it is possible to make many different ITs fail by changing various things in the settings.xml. The ITs I wrote should be overriding the global settings.xml with an empty settings.xml to protect against that type of failure but maybe I needed to override user settings as well? I can't tell right now, we need to see. I worked on MNG-5728 and noticed that many ITs were logically broken and needed fixing. I am quite certain that there will be a fallout. bq. I also wrote tests specifically targeting this bug that was fixed, As mentioned earlier, this isn't a bug, but an abuse of the system. When you modify the IT, you are supposed to supply this with a settings file and boom, your "bugfix" won't work anymore. We expect all ITs to work consistently against Central or a mirrored version of with profiles in the settings file. At the end, most users are corporate ones, only a few write for fun. It worked for your because you have relied on some undocumented behavior (a loop hole). As sad as it sounds and just like [~rfscholte] mentioned, your bugfix will be immediately broken when MNG-4645 will be merged and I am certain that this will happen. Please reconsider fixing your POMs. was (Author: michael-o): [~ewiegs4] > I believe settings.xml always wins over POM (even when directly declared in > the project being built). That's why I fully expect moving Maven central from > the super POM (lowest priority) to the default global settings.xml > (near-highest priority) to break the setup we have where we override central > in the POM. I personally don't like this change as I believe it makes builds > less portable, but I know I'm not going to win that argument so won't go any > further on that point. Central has been embedded into Core for historical reasons. Since many public mirrors are availabe and corporate users like me sit behind Nexus or Artifactory it does not make sense to have this hardcoded, it needs to be swappable. At the end Mavn should not care about Central, it just should know where to download artifacts. It could be even S3 buckets if the structure allows that. > Going back to this particular change, modifying the settings.xml is basically > telling Maven you want it to behave differently on that machine and the > settings usually win over what's in the pom, so I'm sure it is possible to > make many different ITs fail by changing various things in the settings.xml. > The ITs I wrote should be overriding the global settings.xml with an empty > settings.xml to protect against that type of failure but maybe I needed to > override user settings as well? I can't tell right now, we need to see. I worked on MNG-5728 and noticed that many ITs were logically broken and needed fixing. I am quite certain that there will be a fallout. > I also wrote tests specifically targeting this bug that was fixed, As mentioned earlier, this isn't a bug, but an abuse of the system. When you modify the IT, you are supposed to supply this with a settings file and boom, your "bugfix" won't work anymore. We expect all ITs to work consistently against Central or a mirrored version of with profiles in the settings file. At the end, most users are corporate ones, only a few write for fun. It worked for your because you have relied on some undocumented behavior (a loop hole). As sad as it sounds and just like [~rfscholte] mentioned, your bugfix will be immediately broken when MNG-4645 will be merged and I am certain that this will happen. Please reconsider fixing your POMs. > Super POM overwrites remappe
[jira] [Comment Edited] (MNG-6772) Super POM overwrites remapped central repository in nested import POMs
[
https://issues.apache.org/jira/browse/MNG-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236781#comment-17236781
]
Michael Osipov edited comment on MNG-6772 at 11/21/20, 8:12 PM:
[~rfscholte], this has now be merged, but I consider this as code smell and
completely wrong too. Children should have no impact on the parent as well they
should not be able to override repositories. We have {{settings.xml}} for this.
I am officially vetoing this as Maven PMC. Tracking down issues caused by this
will be a pain. Your usecase is broken!
I'd like to stress out that the JFrog Wiki entry does never mention to modify
the POM to override central or any other already existing repo.
I will leave two weeks of discussion before I revert this change.
was (Author: michael-o):
[~rfscholte], this has now be merged, but I consider this as code smell and
completely wrong too. Children should have no impact on the parent as well they
should not be able to override repositories. We have {{settings.xml}} for this.
I am officially vetoing this as Maven PMC. Tracking down issues caused by this
will be a pain. Your usecase is broken!
> 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: 3.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> My projects define a repository with {{central,}} 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)
[jira] [Comment Edited] (MNG-6772) Super POM overwrites remapped central repository in nested import POMs
[
https://issues.apache.org/jira/browse/MNG-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236781#comment-17236781
]
Michael Osipov edited comment on MNG-6772 at 11/21/20, 8:07 PM:
[~rfscholte], this has now be merged, but I consider this as code smell and
completely wrong too. Children should have no impact on the parent as well they
should not be able to override repositories. We have {{settings.xml}} for this.
I am officially vetoing this as Maven PMC. Tracking down issues caused by this
will be a pain. Your usecase is broken!
was (Author: michael-o):
[~rfscholte], this has now be merged, but I consider this as code smell and
completely wrong too. Children should have no impact on the parent as well they
should not be able to override repositories. We have {{settings.xml}} for this.
I am really vetoing this. Tracking down issues caused by this will be a pain.
> 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: 3.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> My projects define a repository with {{central,}} 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)
[jira] [Comment Edited] (MNG-6772) Super POM overwrites remapped central repository in nested import POMs
[
https://issues.apache.org/jira/browse/MNG-6772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16954977#comment-16954977
]
Eddie Wiegers edited comment on MNG-6772 at 10/21/19 3:48 PM:
--
In our case Maven Central is reachable, we are just trying to force our builds
to go through our corporate repository manager for all artifacts instead of
pulling directly from Central. Builds can be performed on a variety of
developer machines, CI nodes, and occasionally separate release build nodes, so
controlling repositories via the POM and having the build be easily
reproducible seems more attractive than having to make sure settings.xml is set
up correctly everywhere. It _almost_ works, but this edge case seems to be one
of the only things that doesn't work. If this setup isn't recommended by the
Maven community then perhaps we'll look into removing all repositories from the
POM and look into the effort to land standard settings everywhere instead.
was (Author: ewiegs4):
In our case Maven Central is reachable, we are just trying to force our builds
to go through our corporate repository manager for all artifacts instead of
pulling directly from Central. Builds can be performed on a variety of
developer machines, CI nodes, and occasionally separate release build nodes, so
controlling repositories via the POM and having the build be easily
reproducible seems more attractive than having to make sure settings.xml is set
up correctly everywhere. It{{ _almost_ }}works, but this edge case seems to be
one of the only things that doesn't work. If this setup isn't recommended by
the Maven community then perhaps we'll look into removing all repositories from
the POM and look into the effort to land standard settings everywhere instead.
> 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
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> My projects define a repository with {{central,}} 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
