[
https://jira.codehaus.org/browse/MNG-5121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279408#comment-279408
]
Benjamin Bentmann commented on MNG-5121:
----------------------------------------
Thanks for example project.
bq. 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.
bq. 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.
> 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
