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

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

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

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

' and 'Vertex

' 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!

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.

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.

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?

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.

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.

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.

This has been resolved with maven 3.0.4