[ 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