Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
2.2-beta-2
-
None
Description
Given the following dependencies in a POM:
<dependency> <groupId>commons-codec</groupId> <artifactId>commons-codec</artifactId> <version>1.3</version> </dependency> <dependency> <groupId>commons-httpclient</groupId> <artifactId>commons-httpclient</artifactId> <version>3.1</version> </dependency>
..and the following assembly descriptor snippet:
<dependencySet> <includes> <include>commons-codec*</include> </includes> <outputDirectory>codec</outputDirectory> <unpack>false</unpack> <useTransitiveDependencies>true</useTransitiveDependencies> </dependencySet> <dependencySet> <includes> <include>commons-httpclient*</include> </includes> <outputDirectory>httpclient</outputDirectory> <useTransitiveDependencies>true</useTransitiveDependencies> <useTransitiveFiltering>true</useTransitiveFiltering> <unpack>false</unpack> </dependencySet>
commons-codec should wind up in both the codec and httpclient dirs, but it's only in the codec dir. The reason for this is found in the maven-artifact code used to resolve dependencies. Since commons-codec is present as a direct dependency, it's removed from the sub-tree rooted by commons-httpclient, and its dependency trail doesn't contain even a whisper of this sub-tree structure. Since the transitive inclusions in dependencySets are calculated using artifact identifications (dependencyConflictId and id itself), along with the dependency trail it contains, the assembly plugin can't see the association between commons-httpclient and commons-codec, resulting in incomplete filtering for the dependencySet.
Attachments
Issue Links
- depends upon
-
MNG-4831 artifact.getDependencyTrail() doesn't include full information; causes problems filtering artifacts by transitive dependency trail
- Closed