[
https://jira.codehaus.org/browse/MNG-4831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Patera updated MNG-4831:
-----------------------------
Attachment: maven-bug-simulation-MNG-4831.zip
Attached a simple example which clearly simulates this issue
([^maven-bug-simulation-MNG-4831.zip]). One can easily play with it to see the
results (just call {{mvn clean verify}} on the multiproject).
B and C both depend on A. In the {{result}} artifact there are two assembly
descriptors to create two ZIP files with the dependencies. If everything
worked, the expected output would be two ZIP files. One with B and A {{jar}}
files. The other with C and A {{jar}} files. However, the result is one ZIP
file with B and A {{jar}} files and the other ZIP file with C {{jar}} only.
As [~rkrell] states, one workaround is to change the order of artifacts (usable
only for one {{maven-assembly-plugin}} configuration in the {{result}}
artifact). The other, perhaps, to create two separate artifacts (one for each
{{maven-assembly-plugin}} configuration) and make sure no filtering on the
dependency tree happens. If necessary, one can play with the [Dependency
Mediation|http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html]
to achieve their goals... None of these workarounds seems nice.
> 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
> Attachments: maven-bug-simulation-MNG-4831.zip
>
>
> 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
