Maven 2 & 3
  1. Maven 2 & 3
  2. MNG-5121

maven seems to lose transitive dependencies from the list of compilation dependencies

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 3.0.1, 3.0.2, 3.0.3
    • Fix Version/s: 3.0.4
    • Component/s: Dependencies
    • Labels:
      None
    • Environment:
      Fedora Linux, Sun JDK 1.6.0_24, MacOS X 10.6.7, AppleJDK 1.6.0_24
    • Complexity:
      Intermediate
    • Testcase included:
      yes
    • Number of attachments :
      4

      Description

      See the attached build logs "build_failed.log" and "build_succesful.log". They were both created from using the attached POM. The only difference is that in the successful build the dependency

      <dependency>
      <groupId>com.google.inject</groupId>
      <artifactId>guice</artifactId>
      <version>3.0</version>
      </dependency>

      is moved to the very top of the dependency list. When diffing the two build logs, the most important difference is that in the failed log maven picks up these dependencies:

      [DEBUG] com.google.inject:guice:jar:3.0:compile

      while in the successful build, the same dependency looks like this:

      [DEBUG] com.google.inject:guice:jar:3.0:compile
      [DEBUG] javax.inject:javax.inject:jar:1:compile
      [DEBUG] aopalliance:aopalliance:jar:1.0:

      This translates for the successful build into:

      [DEBUG] Classpath: [/Users/henning/private/source/services/thetargetproject/target/classes
      /Users/henning/.m2/repository/com/google/inject/guice/3.0/guice-3.0.jar
      /Users/henning/.m2/repository/javax/inject/javax.inject/1/javax.inject-1.jar
      [...]

      and for the failed build:

      [DEBUG] Classpath: [...]
      /Users/henning/.m2/repository/com/google/inject/guice/3.0/guice-3.0.jar
      [...]

      (note that even for the successful build, the aopalliance dependency still got dropped).

      This behaviour started with maven 3.x, all permutations of the dependencies build fine with maven 2.2.1

      This problem can be reproduced in all maven 3.0.x versions (.1, .2 and .3).

      In both cases, the transitive dependencies of guice 3.0 (javax.inject:javax.inject and aopalliance:aopalliance) should always be present.

      The same behaviour occurs in the exec-maven-plugin which uses the runtime dependency path to execute java code.

      1. build_failed.log
        104 kB
        Henning Schmiedehausen
      2. build_successful.log
        188 kB
        Henning Schmiedehausen
      3. maven-pom.xml
        6 kB
        Henning Schmiedehausen
      4. mng-5121.tgz
        2 kB
        Steven Schlansker

        Activity

        Hide
        Benjamin Bentmann added a comment -

        A characteristic of the logs provided by Henning was the complete absence of javax.inject in the failing case whereas in your example the troublesome dependency was at least mentioned in the dependency graph albeit with a missing scope. Considering the way the dependency tree is constructed, those defects hint at different underlying issues. But anyways, if both projects get correct dependency trees using the recent JARs, there is probably not much gained from hunting this discrepancy down.

        Show
        Benjamin Bentmann added a comment - A characteristic of the logs provided by Henning was the complete absence of javax.inject in the failing case whereas in your example the troublesome dependency was at least mentioned in the dependency graph albeit with a missing scope. Considering the way the dependency tree is constructed, those defects hint at different underlying issues. But anyways, if both projects get correct dependency trees using the recent JARs, there is probably not much gained from hunting this discrepancy down.
        Hide
        Steven Schlansker added a comment -

        That was always the behavior - even in the failing cases, it was always present in dependency:tree even if it did not appear in the class path in the appropriate place. At least, that is my understanding.

        Show
        Steven Schlansker added a comment - That was always the behavior - even in the failing cases, it was always present in dependency:tree even if it did not appear in the class path in the appropriate place. At least, that is my understanding.
        Hide
        Benjamin Bentmann added a comment -

        I was referring to the trees in the debug log from Henning, not the output of mvn dependency:tree which does not necessarily reflect core behavior.

        Show
        Benjamin Bentmann added a comment - I was referring to the trees in the debug log from Henning, not the output of mvn dependency:tree which does not necessarily reflect core behavior.
        Hide
        Henning Schmiedehausen added a comment -

        This has been resolved with maven 3.0.4

        Show
        Henning Schmiedehausen added a comment - This has been resolved with maven 3.0.4
        Hide
        Edgar Vonk added a comment -

        I just seem to run into this very same issue if I am not mistaken using Maven 3.2.1. Could it be that maybe MNG-2315 re-introduced this bug? Could someone maybe have a look? If not then something else is going on.

        In any case with Maven 3.2.1 I had a very similar situation where it seems that all transitive dependencies were lost from my JAR file (starting with the javax.inject dependency). I then downgraded to Maven 3.1.1, rebuild my JAR and now all transitive dependencies are back again.

        Show
        Edgar Vonk added a comment - I just seem to run into this very same issue if I am not mistaken using Maven 3.2.1. Could it be that maybe MNG-2315 re-introduced this bug? Could someone maybe have a look? If not then something else is going on. In any case with Maven 3.2.1 I had a very similar situation where it seems that all transitive dependencies were lost from my JAR file (starting with the javax.inject dependency). I then downgraded to Maven 3.1.1, rebuild my JAR and now all transitive dependencies are back again.

          People

          • Assignee:
            Jason van Zyl
            Reporter:
            Henning Schmiedehausen
          • Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: