[
https://jira.codehaus.org/browse/MNG-4831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=304385#comment-304385
]
Rene Krell commented on MNG-4831:
---------------------------------
Some quick and dirty workaround: Reordering of the dependencies in the POM, to
get the dependencies used further in a dependencyset in maven-assembly-plugin
at the first place, and not filtering out its transitive dependencies too
early. But this may still fail if there are used multiple assembly decriptors
in one module where the order can't be defined in that way.
Thus, even worse, the transitive dependencies are brought in depending on the
order their "parents" are defined in the POM. This seems to to be nothing more
than some optimalization in the Maven core, but unfortunately bad for using in
plugins.
> artifact.getDependencyTrail() doesn't include full information; causes
> problems filtering artifacts by transitive dependency trail
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: MNG-4831
> URL: https://jira.codehaus.org/browse/MNG-4831
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Artifacts and Repositories
> Affects Versions: 2.2.1, 3.0-beta-3
> Reporter: John Casey
>
> Artifact.getDependencyTrail() is a List, not a graph. This means the artifact
> doesn't include information about every artifact that depends on that
> artifact.
> In cases where the project's artifacts are filtered using the dependency
> trail, it can become impossible to capture the full dependency closure for an
> included artifact if that artifact depends on something that an excluded
> artifact also depends on.
> For a concrete example / test case of this, see MASSEMBLY-504.
> In this example, A and B both depend on C. However, the dependencySet
> _excludes_ B from the assembly. By luck of the draw, profile dependencies are
> appended to the project's other dependencies, and B is in the dependencyTrail
> of C, not A (both are valid to be there). Since transitive filtering is
> enabled, C is _excluded_ from the assembly along with B, and the classpath
> for A is not fully represented.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
