[jira] (MNG-4831) artifact.getDependencyTrail() doesn't include full information; causes problems filtering artifacts by transitive dependency trail

["Jiri Patera (JIRA)" <ji...@codehaus.org>]

     [ 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