You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "John Casey (JIRA)" <ji...@codehaus.org> on 2010/09/22 19:09:32 UTC
[jira] Created: (MNG-4831) artifact.getDependencyTrail() doesn't
include full information; causes problems filtering artifacts by transitive
dependency trail
artifact.getDependencyTrail() doesn't include full information; causes problems filtering artifacts by transitive dependency trail
----------------------------------------------------------------------------------------------------------------------------------
Key: MNG-4831
URL: http://jira.codehaus.org/browse/MNG-4831
Project: Maven 2 & 3
Issue Type: Improvement
Components: Artifacts and Repositories
Affects Versions: 3.0-beta-3, 2.2.1
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 contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4831) artifact.getDependencyTrail() doesn't include
full information; causes problems filtering artifacts by transitive
dependency trail
Posted by "Rene Krell (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MNG-4831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=304325#comment-304325 ]
Rene Krell commented on MNG-4831:
---------------------------------
Has there been any progress with this issue? Maybe in newer Maven versions?
Actually, loosing transitive dependencies just because they are filtered out in the appropriate POM makes using of dependencysets with maven-assembly-plugin very difficult (tested with Maven 2.2.1).
> 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
[jira] (MNG-4831) artifact.getDependencyTrail() doesn't include
full information; causes problems filtering artifacts by transitive
dependency trail
Posted by "Rene Krell (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MNG-4831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=304325#comment-304325 ]
Rene Krell edited comment on MNG-4831 at 7/23/12 9:00 AM:
----------------------------------------------------------
Has there been any progress with this issue? Maybe in newer Maven versions?
Actually, loosing transitive dependencies just because they are filtered out in the appropriate POM based on the order they are defined in the POM makes using of dependencysets with maven-assembly-plugin difficult and intransparent(tested with Maven 2.2.1).
was (Author: rkrell):
Has there been any progress with this issue? Maybe in newer Maven versions?
Actually, loosing transitive dependencies just because they are filtered out in the appropriate POM makes using of dependencysets with maven-assembly-plugin very difficult (tested with Maven 2.2.1).
> 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
[jira] (MNG-4831) artifact.getDependencyTrail() doesn't include
full information; causes problems filtering artifacts by transitive
dependency trail
Posted by "Rene Krell (JIRA)" <ji...@codehaus.org>.
[ 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
[jira] (MNG-4831) artifact.getDependencyTrail() doesn't include
full information; causes problems filtering artifacts by transitive
dependency trail
Posted by "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