If the shaded artifact is built as a submodule with a different artifact
ID, then the shade plugin can specify its DRP as its main POM. It lets
other projects depend on the shaded artifact with only its remaining
(unshaded) dependencies.
I had tried to use the shade plugin along with the install & deploy
plugins so that I could build the main project, shaded artifact, and DRP
within a single POM, but was told that such practice was contrary to the
maven philosophy of all artifacts produced by a given POM have that POM
as its parent. So moving shade into a submodule with settings like this
was the only solution I could find that works:
<createDependencyReducedPom>true</createDependencyReducedPom>
<keepDependenciesWithProvidedScope>false</keepDependenciesWithProvidedScope>
<shadedArtifactAttached>false</shadedArtifactAttached>
Not sure if this adds anything to the thread but it worked for me
-Richard
------ Original Message ------
From: "grahamtriggs" <[email protected]>
To: [email protected]
Sent: 4/27/2017 1:30:24 PM
Subject: [GitHub] maven issue #69: MNG-5899 Reactor should use reduced
dependency pom
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.
---
If your project is set up for it, you can reply to this email and have
your
reply appear on GitHub as well. If your project does not have this
feature
enabled and wishes so, or if the feature is enabled but not working,
please
contact infrastructure at [email protected] or file a JIRA
ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
