Maven
  1. Maven
  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 -

        This likely requires a runnable test project for proper analysis and fixing.

        Show
        Benjamin Bentmann added a comment - This likely requires a runnable test project for proper analysis and fixing.
        Hide
        Steven Schlansker added a comment - - edited

        After a rather annoying amount of work, here is an executable test case, attached.

        Show
        Steven Schlansker added a comment - - edited After a rather annoying amount of work, here is an executable test case, attached.
        Hide
        Steven Schlansker added a comment -

        More specifics about the test case:

        In the process of isolating it, I discovered that we inadvertently introduced a build cycle between different versions. The project as bundled is a large multi module build, which maven 2 (probably correctly) rejects due to:

        Project 'io.trumpet.components:tc-tracking' is duplicated in the reactor

        If you remove one of them from the reactor, the error message changes to:

        The projects in the reactor contain a cyclic reference: Edge between 'Vertex

        {label='io.trumpet.components:tc-httpclient'}

        ' and 'Vertex

        {label='io.trumpet.components:tc-tracking'}

        ' introduces to cycle in the graph io.trumpet.components:tc-tracking --> io.trumpet.components:tc-httpclient --> io.trumpet.components:tc-tracking

        Interestingly enough, this cycle was not detected in our (much larger, "real life") code base - Maven 2 somehow misses the error but completes the build successfully. I assume that Maven 2 is now being phased out and further development is focused on 3, but if you would like a separate test case to show this issue I could try to isolate it.

        Now, on to Maven 3 - the project as bundled is considered valid (even though it likely should not be, given that there is a dependency cycle that Maven 2 noticed). It bravely forges ahead but loses some transitive dependencies along the way – leading to an eventual

        [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project mng-5121: Compilation failure: Compilation failure:
        [ERROR] /Volumes/Zoom/code/maven-bugs/mng-5121/badness/src/main/java/testing/Badness.java:[3,23] package org.slf4j.bridge does not exist
        [ERROR] /Volumes/Zoom/code/maven-bugs/mng-5121/badness/src/main/java/testing/Badness.java:[7,8] cannot find symbol
        [ERROR] symbol : variable SLF4JBridgeHandler
        [ERROR] location: class testing.Badness

        The SLF4JBridgeHandler is from jul-to-slf4j, which is clearly in the dependencies:

        [INFO] — maven-dependency-plugin:2.1:tree (default-cli) @ mng-5121 —
        [INFO] io.trumpet.testing:mng-5121:jar:1.0-SNAPSHOT
        [INFO] +- io.trumpet.components:tc-log:jar:5.0-BOGUS:compile
        [INFO] | - org.slf4j:jul-to-slf4j:jar:1.6.1:compile
        [INFO] | - org.slf4j:slf4j-api:jar:1.6.1:compile
        [INFO] - io.trumpet.testing:tc-message-storage:jar:1.0-SNAPSHOT:compile
        [INFO] - io.trumpet.testing:tc-clients-base:jar:1.0-SNAPSHOT:compile
        [INFO] - io.trumpet.components:tc-tracking:jar:7.0-BOGUS:compile
        [INFO] - io.trumpet.components:tc-httpclient:jar:10.0-BOGUS:compile

        But it does not make it to the runtime class path somehow.

        Since this is arguably an invalid project setup, it is not clear to me whether Maven should handle it, but whether it does or does not it would be insanely useful to detect invalid projects like this and warn. Maven 2 seems to have caught it in the "smaller" test case but did not notice it in our "larger" world – and Maven 3 doesn't notice at all.

        More than willing to provide more information as requested, hopefully this is detailed enough to work on. Thank you much for your looking in to this bug!

        Show
        Steven Schlansker added a comment - More specifics about the test case: In the process of isolating it, I discovered that we inadvertently introduced a build cycle between different versions. The project as bundled is a large multi module build, which maven 2 (probably correctly) rejects due to: Project 'io.trumpet.components:tc-tracking' is duplicated in the reactor If you remove one of them from the reactor, the error message changes to: The projects in the reactor contain a cyclic reference: Edge between 'Vertex {label='io.trumpet.components:tc-httpclient'} ' and 'Vertex {label='io.trumpet.components:tc-tracking'} ' introduces to cycle in the graph io.trumpet.components:tc-tracking --> io.trumpet.components:tc-httpclient --> io.trumpet.components:tc-tracking Interestingly enough, this cycle was not detected in our (much larger, "real life") code base - Maven 2 somehow misses the error but completes the build successfully. I assume that Maven 2 is now being phased out and further development is focused on 3, but if you would like a separate test case to show this issue I could try to isolate it. Now, on to Maven 3 - the project as bundled is considered valid (even though it likely should not be, given that there is a dependency cycle that Maven 2 noticed). It bravely forges ahead but loses some transitive dependencies along the way – leading to an eventual [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project mng-5121: Compilation failure: Compilation failure: [ERROR] /Volumes/Zoom/code/maven-bugs/mng-5121/badness/src/main/java/testing/Badness.java: [3,23] package org.slf4j.bridge does not exist [ERROR] /Volumes/Zoom/code/maven-bugs/mng-5121/badness/src/main/java/testing/Badness.java: [7,8] cannot find symbol [ERROR] symbol : variable SLF4JBridgeHandler [ERROR] location: class testing.Badness The SLF4JBridgeHandler is from jul-to-slf4j, which is clearly in the dependencies: [INFO] — maven-dependency-plugin:2.1:tree (default-cli) @ mng-5121 — [INFO] io.trumpet.testing:mng-5121:jar:1.0-SNAPSHOT [INFO] +- io.trumpet.components:tc-log:jar:5.0-BOGUS:compile [INFO] | - org.slf4j:jul-to-slf4j:jar:1.6.1:compile [INFO] | - org.slf4j:slf4j-api:jar:1.6.1:compile [INFO] - io.trumpet.testing:tc-message-storage:jar:1.0-SNAPSHOT:compile [INFO] - io.trumpet.testing:tc-clients-base:jar:1.0-SNAPSHOT:compile [INFO] - io.trumpet.components:tc-tracking:jar:7.0-BOGUS:compile [INFO] - io.trumpet.components:tc-httpclient:jar:10.0-BOGUS:compile But it does not make it to the runtime class path somehow. Since this is arguably an invalid project setup, it is not clear to me whether Maven should handle it, but whether it does or does not it would be insanely useful to detect invalid projects like this and warn. Maven 2 seems to have caught it in the "smaller" test case but did not notice it in our "larger" world – and Maven 3 doesn't notice at all. More than willing to provide more information as requested, hopefully this is detailed enough to work on. Thank you much for your looking in to this bug!
        Hide
        Benjamin Bentmann added a comment -

        Thanks for example project.

        Now, on to Maven 3 - the project as bundled is considered valid (even though it likely should not be, given that there is a dependency cycle that Maven 2 noticed)

        First, artifacts and projects are versioned items and A:1 is different from A:2. As such, a dependency graph like A:2 -> B:1 -> A:1 does not contain a cycle, whether one likes such a project design is a different matter. So yes, your example project is technically valid.

        It bravely forges ahead but loses some transitive dependencies

        In fact, the dependency on jul-to-slf4j is not entirely lost but its scope gets miscalculated as seen in the dependency tree from the debug log. This is a bug that has already been reported before and can be fixed by replacing the aether-* JARs in your mvn distro with newer versions (1.12 or 1.13).

        The debug log obtained from your example project further suggests that this is not the same issue that Henning originally reported where dependencies were completely missing from the dependency graph.

        Show
        Benjamin Bentmann added a comment - Thanks for example project. Now, on to Maven 3 - the project as bundled is considered valid (even though it likely should not be, given that there is a dependency cycle that Maven 2 noticed) First, artifacts and projects are versioned items and A:1 is different from A:2. As such, a dependency graph like A:2 -> B:1 -> A:1 does not contain a cycle, whether one likes such a project design is a different matter. So yes, your example project is technically valid. It bravely forges ahead but loses some transitive dependencies In fact, the dependency on jul-to-slf4j is not entirely lost but its scope gets miscalculated as seen in the dependency tree from the debug log. This is a bug that has already been reported before and can be fixed by replacing the aether-* JARs in your mvn distro with newer versions (1.12 or 1.13). The debug log obtained from your example project further suggests that this is not the same issue that Henning originally reported where dependencies were completely missing from the dependency graph.
        Hide
        Steven Schlansker added a comment -

        Hrrrm. I was trying to reproduce the same issue but was paring down the test case (we have probably hundreds of dependencies involved otherwise) and this is what I came up with. I will try to work from Henning's example pom, rather than our code base, and see if I can come up with different reproduction steps.

        Show
        Steven Schlansker added a comment - Hrrrm. I was trying to reproduce the same issue but was paring down the test case (we have probably hundreds of dependencies involved otherwise) and this is what I came up with. I will try to work from Henning's example pom, rather than our code base, and see if I can come up with different reproduction steps.
        Hide
        Steven Schlansker added a comment - - edited

        I downloaded Henning's POM file, and tested it locally. With the versions that included the same dependency loop, the compile fails with

        Compilation failure: Compilation failure:
        [ERROR] /Volumes/Zoom/code/maven-bugs/mng-5121-a/src/main/java/testing/Badness.java:[3,19] package javax.inject does not exist
        [ERROR] /Volumes/Zoom/code/maven-bugs/mng-5121-a/src/main/java/testing/Badness.java:[7,27] cannot find symbol

        which matches the problem as described. When I remove the dependency loop, it prints out many "[WARNING] The POM for io.trumpet.components:tc-config:jar:4.0 is missing, no dependency information available" but compiles and runs successfully.

        Additionally, downloading the new aether jars as you suggest fixed both the test case I had and Henning's test case.

        So I am suspecting that it is actually the same problem, and that it is indeed fixed with a new version of aether - do you have any other reason to believe it is not?

        Show
        Steven Schlansker added a comment - - edited I downloaded Henning's POM file, and tested it locally. With the versions that included the same dependency loop, the compile fails with Compilation failure: Compilation failure: [ERROR] /Volumes/Zoom/code/maven-bugs/mng-5121-a/src/main/java/testing/Badness.java: [3,19] package javax.inject does not exist [ERROR] /Volumes/Zoom/code/maven-bugs/mng-5121-a/src/main/java/testing/Badness.java: [7,27] cannot find symbol which matches the problem as described. When I remove the dependency loop, it prints out many " [WARNING] The POM for io.trumpet.components:tc-config:jar:4.0 is missing, no dependency information available" but compiles and runs successfully. Additionally, downloading the new aether jars as you suggest fixed both the test case I had and Henning's test case. So I am suspecting that it is actually the same problem, and that it is indeed fixed with a new version of aether - do you have any other reason to believe it is not?
        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: