Maven Dependency Plugin
  1. Maven Dependency Plugin
  2. MDEP-251

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

        Herve Boutemy made changes -
        Field Original Value New Value
        Summary Artifacts qualifier are taken into accounts correctly Artifacts qualifier are NOT taken into accounts correctly
        Herve Boutemy made changes -
        Comment [ Sorry, made a mistake on the issue name itself. It should be:

        Artifacts qualifier are NOT taken into accounts correctly

        There don't seem to be a way to edit this Issue name. ]
        Andreas Brieg made changes -
        Attachment test.maven-dependency-plugin.zip [ 52276 ]
        Paul Gier made changes -
        Component/s tree [ 12849 ]
        Herve Boutemy made changes -
        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
        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:

        {noformat}[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{noformat}

        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:

        {noformat}[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
        ...{noformat}

        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:

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

        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
        Herve Boutemy made changes -
        Assignee Brian Fox [ brianfox ]
        Herve Boutemy made changes -
        Priority Critical [ 2 ] Minor [ 4 ]

          People

          • Assignee:
            Unassigned
            Reporter:
            Jean Seurin
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated: