Maven 2 & 3

artifact.getDependencyTrail() doesn't include full information; causes problems filtering artifacts by transitive dependency trail

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 2.2.1, 3.0-beta-3
  • Fix Version/s: None
  • Component/s: Artifacts and Repositories
  • Labels:
    None
  • Complexity:
    Intermediate
  • Number of attachments :
    1

Description

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.

Issue Links

is depended upon by

Bug - A problem which impairs or prevents the functions of the product. MASSEMBLY-357 transitive dependencies erroneously excluded from dependencySet in some cases

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Bug - A problem which impairs or prevents the functions of the product. MASSEMBLY-504 Transitive dependencies missing when two deps rely on them, but one of the deps is excluded

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
John Casey added a comment -

Cannot fix assembly transitive filtering where there is an overlap of transitive dependencies until this is fixed in maven itself.

Show
John Casey added a comment - Cannot fix assembly transitive filtering where there is an overlap of transitive dependencies until this is fixed in maven itself.
Hide
Permalink
Rene Krell added a comment - - edited

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).

Show
Rene Krell added a comment - - edited 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).
Hide
Permalink
Rene Krell added a comment -

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.

Show
Rene Krell added a comment - 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.
Hide
Permalink
Jiri Patera added a comment -

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 Rene Krell 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 to achieve their goals... None of these workarounds seems nice.

Show
Jiri Patera added a comment - 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 Rene Krell 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 to achieve their goals... None of these workarounds seems nice.

People

  • Assignee:
    Unassigned
    Reporter:
    John Casey
Vote (5)
Watch (3)

Dates

  • Created:
    Updated: