Description

(Not sure what the right place to file this is. maven-dependency-tree 1.2 gives MNG as the JIRA component by inheritance.)

mvn dependency:tree on the attached project lists batik-script by way of batik-bridge as expected, but then fails to show batik-js as a dependency of that. If you list batik-script as a direct dependency, batik-js is correctly shown.

Possibly related is that Maven 2.2.1 also fails to find batik-js in MavenProject.getRuntimeArtifacts, so clean package fails, whereas this works fine under Maven 3.0. Yet just running the dependency plugin under M3 does not suffice to pick up this fix, wherever it was - MNG-4690?

Although the Batik JARs are built from an odd source tree, the artifacts as present in the local repository look normal enough; all of the dependencies involved are simple compile scope without exclusions etc.

Marking "major" since this seems to cause MNBMODULE-102 (producing build errors for certain projects); also I have noticed that the dependency graph feature in the NB IDE omits batik-js, and there may be other user-visible effects of this bug.

I see. Should maven-dependency-tree then be considered fully deprecated? If so, is there some plan to release a fixed maven-dependency-plugin; and is there some documentation on which API in Maven core (or Aether) should be used in place of the deprecated component?

Jesse Glick
added a comment - 19/Oct/10 9:58 AM I see. Should maven-dependency-tree then be considered fully deprecated? If so, is there some plan to release a fixed maven-dependency-plugin; and is there some documentation on which API in Maven core (or Aether) should be used in place of the deprecated component?

at org.apache.maven.project.DefaultProjectDependenciesResolver$GraphLogger.visitEnter(DefaultProjectDependenciesResolver.java:223)
at org.sonatype.aether.impl.internal.GraphEdge.accept(GraphEdge.java:173)
at org.sonatype.aether.impl.internal.GraphEdge.accept(GraphEdge.java:177)
at org.sonatype.aether.impl.internal.GraphEdge.accept(GraphEdge.java:177)
at org.sonatype.aether.impl.internal.GraphEdge.accept(GraphEdge.java:177)
at org.sonatype.aether.impl.internal.GraphEdge.accept(GraphEdge.java:177)
at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:145)

Jesse Glick
added a comment - 01/Nov/10 1:50 PM The above tree seems to be printed by:
at org.apache.maven.project.DefaultProjectDependenciesResolver$GraphLogger.visitEnter(DefaultProjectDependenciesResolver.java:223)
at org.sonatype.aether.impl.internal.GraphEdge.accept(GraphEdge.java:173)
at org.sonatype.aether.impl.internal.GraphEdge.accept(GraphEdge.java:177)
at org.sonatype.aether.impl.internal.GraphEdge.accept(GraphEdge.java:177)
at org.sonatype.aether.impl.internal.GraphEdge.accept(GraphEdge.java:177)
at org.sonatype.aether.impl.internal.GraphEdge.accept(GraphEdge.java:177)
at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:145)

David Tombs
added a comment - 13/Sep/11 9:52 AM This issue just caused me some grief. Could this discrepancy between dependency:tree and the actual tree used possibly be documented in the dependency:tree docs?

this component has a Maven 2 implementation using "usual" DependencyTreeBuilder and a Maven 3 implementation using Maven 3 with Aether
Default implementation detects current Maven version and automatically switches between the 2

Herve Boutemy
added a comment - 10/Jun/12 4:20 PM new DependencyGraphBuilder component created in r1348663
this component has a Maven 2 implementation using "usual" DependencyTreeBuilder and a Maven 3 implementation using Maven 3 with Aether
Default implementation detects current Maven version and automatically switches between the 2