[
https://issues.apache.org/jira/browse/MNG-5899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15987102#comment-15987102
]
ASF GitHub Bot commented on MNG-5899:
-------------------------------------
Github user grahamtriggs commented on the issue:
https://github.com/apache/maven/pull/69
> Mutated pom.xml files must not invalidate original reactor
ProjectDependencyGraph. More specifically, if the original graph allowed
certain build order, the new graph must still allow the same order.
That might be a practical limitation right now, but I wouldn't mind having
a dynamic build order. The two things that should matter are that builds
complete, and have the same final outcome. Dealing with the issues of being
able "pull up" a dependency in the reactor, and knowing what can be built / is
waiting on something else to be built might actually benefit scalability with
parallel executions.
Seems like there is a more important design question here - should a
project, when built and installed to a repository, then depended on by a
completely separate build behave the same when it is included in a reactor?
If you can create an artifact, and a custom pom for install / deployment to
a repository that differs from the project pom, then to my mind that should be
what is seen by any module including it as a dependency, even in the same
reactor.
The concern is about adding new dependencies, and whilst that is
technically possible, I'm not sure that it needs to be supported - it could
have just been made a dependency of the project anyway.
The real issue - particularly with the shade plugin - is that you want to
embed things in an artifact, and not have other projects having to try and pull
them in as dependencies. To be honest, it would actually be better if this was
native to the pom, rather than part of the shade plugin, because then you could
express what dependencies you want to embed, and this information would then be
communicated to other projects depending on it. Then they would not only not
pull in the transitive dependency for the embedded code, they would also be
able to determine if the embedded version is compatible with their requirements.
> Reactor is no longer using the dependency reduced pom created by
> maven-shade-plugin
> -----------------------------------------------------------------------------------
>
> Key: MNG-5899
> URL: https://issues.apache.org/jira/browse/MNG-5899
> Project: Maven
> Issue Type: Bug
> Affects Versions: 3.3.1, 3.3.3
> Reporter: Trask Stalnaker
>
> This works with maven 3.2.5 and prior, but does not work with the latest
> releases (3.3.1 and 3.3.3), or master (tested against 3.3.7-SNAPSHOT).
> I did some bisecting and found the commit that caused the breakage:
> https://github.com/apache/maven/commit/be3fb200326208ca4b8c41ebf16d5ae6b8049792
> In particular, this commit introduced some code to not rebuild the model if
> it was already loaded during reactor resolution.
> This is causing maven not to use the dependency reduced pom created by the
> maven-shade-plugin.
> Removing this code fixes the situation. I'm hoping that code was just
> introduced as a performance optimization, and that I haven't broken anything
> functionally by removing it (the tests still pass at least).
> I will submit a pull request with the change for review.
> Here is the original maven-shade-plugin issue as reported by the Apache Storm
> team: https://issues.apache.org/jira/browse/MSHADE-206
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
