Maven 2.x Dependency Plugin

Artifacts qualifier are NOT taken into accounts correctly

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: 2.1
  • Fix Version/s: None
  • Component/s: tree
  • Labels:
    None
  • Environment:
    OSX 10.6.2, java 1.6.0_17
  • Number of attachments :
    1

Description

I just introduced some qualifier for some libs that require to be compiled in java5.
I've been very confused when realizing that when packaging a webapp depending on those qualified artifacts, the non qualified versions are included instead.

It seems to come from dependency plugin.

Here is what happens:

When I do a dependency:tree on an artifact that depends directly on qualified libs, I get something regular:

[INFO] [dependency:tree {execution: default-cli}]
[INFO] org.company.project:stageof:jar:1.4-SNAPSHOT
[INFO] +- org.company.project:jar:jdk1.5:1.5-SNAPSHOT:compile
....
[INFO] +- org.company.commons:commons-xml:jar:jdk1.5:1.4-SNAPSHOT:compile

The stageof lib depends on the jdk1.5 qualified commons and commons-xml libs.

When I do a dependency:tree on an upper level webapp that depends on this stageof lib:

[INFO] org.company.project:webapp:war:1.13-SNAPSHOT
[INFO] +- org.company.project:stageof:jar:jdk1.5:1.4-SNAPSHOT:compile
[INFO] |  +- org.company.commons:jar:1.4.0:compile
[INFO] |  \- org.company.commons:commons-xml:jar:1.4-SNAPSHOT:compile
[INFO] +- org.company.commons:jar:jdk1.5:1.5-SNAPSHOT:compile
...

it finds correctly the qualified version of stageof, but include non qualified commons and commons-xml.

These unqualified versions are the dependencies of the also non qualified stageof-1.4-SNAPSHOT.

From this behavior, I presume dependency plugin makes a mistake in looking from the wrong pom, probably not using the qualifier of the included dependency:

        <dependency>
            <groupId>org.company.project</groupId>
            <artifactId>stageof</artifactId>
            <version>1.4-SNAPSHOT</version>
            <scope>compile</scope>
            <classifier>jdk1.5</classifier>
        </dependency>

Hope this is clear.
I could provide an example if you can't reproduce easily.
Actually, just adding a qualifier to the jar-plugin to produce the artifact and to the <dependency> section should do the job.

rgds,
jean

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Brian Fox added a comment -

Please provide a test project. Also the dependency plugin reports on the resolution it doesn't do the resolution itself. It appears to me you are talking about a core issue and not one in the plugin but without a sample I can't be sure.

Show
Brian Fox added a comment - Please provide a test project. Also the dependency plugin reports on the resolution it doesn't do the resolution itself. It appears to me you are talking about a core issue and not one in the plugin but without a sample I can't be sure.
Hide
Permalink
Andreas Brieg added a comment - - edited

I attached a file, which shows an incorrect behavior with classifiers. The project has a dependency on a zip file with no classifier. A second dependency is within a profile, which is active by default. The dependency in the profile uses a classifier. The maven dependency plugin tries to download the dependency, which is not in the profile, with the classifier of the dependency in the profile.

Please note that there must not exist any dependency listed in the project in your maven repositories in order to demonstrate the incorrect behavior.

Show
Andreas Brieg added a comment - - edited I attached a file, which shows an incorrect behavior with classifiers. The project has a dependency on a zip file with no classifier. A second dependency is within a profile, which is active by default. The dependency in the profile uses a classifier. The maven dependency plugin tries to download the dependency, which is not in the profile, with the classifier of the dependency in the profile. Please note that there must not exist any dependency listed in the project in your maven repositories in order to demonstrate the incorrect behavior.
Hide
Permalink
Jörg Schaible added a comment -

@Andreas Brieg: Maven is absolute correct. Different classifier (even "no classifier") address distinct dependencies. What you do in your profile is simply adding a second dependency and Maven behaves accordingly.

Show
Jörg Schaible added a comment - @Andreas Brieg: Maven is absolute correct. Different classifier (even "no classifier") address distinct dependencies. What you do in your profile is simply adding a second dependency and Maven behaves accordingly.
Hide
Permalink
Andreas Brieg added a comment -

@Joerg Schaible:
Looking at the attached test project I would expect that the maven dependency plugin tries to download some-zip-0.0.1-SNAPSHOT.zip and not some-zip-0.0.1-SNAPSHOT-x86.zip because this artifact does not specify a classifier.

Even if I add another profile with another classifier the dependency plugin will use the latest specified classifier for some-zip-0.0.1-SNAPSHOT.zip. So if using maven in a complex multi module project one would have to install/deploy all possible modules to the repository with every possible classifier. But that would just be redundant, because the majority of modules wouldn't have differences for different classifiers.

Show
Andreas Brieg added a comment - @Joerg Schaible: Looking at the attached test project I would expect that the maven dependency plugin tries to download some-zip-0.0.1-SNAPSHOT.zip and not some-zip-0.0.1-SNAPSHOT-x86.zip because this artifact does not specify a classifier. Even if I add another profile with another classifier the dependency plugin will use the latest specified classifier for some-zip-0.0.1-SNAPSHOT.zip . So if using maven in a complex multi module project one would have to install/deploy all possible modules to the repository with every possible classifier. But that would just be redundant, because the majority of modules wouldn't have differences for different classifiers.

People

  • Assignee:
    Unassigned
    Reporter:
    Jean Seurin
Vote (1)
Watch (3)

Dates

  • Created:
    Updated: