[
https://jira.codehaus.org/browse/MNG-5121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279371#comment-279371
]
Steven Schlansker commented on MNG-5121:
----------------------------------------
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!
> maven seems to lose transitive dependencies from the list of compilation
> dependencies
> -------------------------------------------------------------------------------------
>
> Key: MNG-5121
> URL: https://jira.codehaus.org/browse/MNG-5121
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
> Affects Versions: 3.0.1, 3.0.2, 3.0.3
> Environment: Fedora Linux, Sun JDK 1.6.0_24, MacOS X 10.6.7, AppleJDK
> 1.6.0_24
> Reporter: Henning Schmiedehausen
> Priority: Blocker
> Attachments: build_failed.log, build_successful.log, maven-pom.xml,
> mng-5121.tgz
>
>
> 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.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
