Transitive dependencies incorrectly processed in Maven 3

Your problem is that you have a jar-packaging project with a dependency on an nbm-packaging project, and then you are trying to use this as a dependency of another nbm-packaging project. I don't think this should be supported; nbm -> jar dependencies imply creating a library wrapper module, which is not going to work correctly here. That said, it is interesting that the plugin accepted this configuration under Maven 2.

Actually the problem seems to have something to do with org.mozilla.javascript.* classes, which I am investigating. The nbm -> jar -> nbm dependency was also a bad idea and is warned about using either Maven 2 or 3 - you should switch packaging of test2:test2.nvc.widget to nbm and include it as a module in test2:test2.gui - but that does not seem to be causing the build error.

Workaround:

                <exclusion>
                    <groupId>org.apache.xmlgraphics</groupId>
                    <artifactId>batik-js</artifactId>
                </exclusion>

I think something is wrong with maven-dependency-tree, since mvn -f nvc/widget/pom.xml dependency:tree omits batik-js for no clear reason. This however happens even under Maven 2.

The difference is that in Maven 2, MavenProject.getRuntimeArtifacts also incorrectly omits batik-js, and some set subtraction is going on.

I would like to explain why we use jar packaging project and not nbm packaging. In a real life we use this module for two independent projects. The first one is based on the Netbeans RCP and the second one is based on Swing Application Framework with Netbeans Visual Library. I assume that we can use this library in a similar way as any other swing library (freechart,...) and it is a reason why we use jar packaging. Or is this idea incorrect?

I do not plan to work on this in the near future, at least until maven-dependency-plugin is fixed so that I can see what kind of changes are required to convert code using maven-dependency-tree to Aether. I did not write the code in the plugin which uses this old library and I do not really understand what it is doing.

In the meantime, the workaround is straightforward: avoid implicit transitive dependencies, by fixing up your POM until maven-dependency-plugin's output looks the way you want.

I played with the legacy ArtifactCollector but it does not work, even when run from M3; the ResolutionNode for batik-script shows no children. I guess the old buggy code was just copied into M3 unmodified. Maybe org.sonatype.aether.graph.DependencyNode is what new code ought to be using, but I don't suppose I can use this from a plugin that needs to run in both M2 and M3, and the API looks fairly different.

The background is that nbm-maven-plugin does rather exotic things with dependencies, since Maven's dependency tree works very differently from NB module dependencies:

1. NB does not do transitive dependencies, so indirect dependencies reported by Maven may need to be added to OpenIDE-Module-Module-Dependencies even though they do not appear in your POM. There is also special handling for OSGi bundles.

2. The plugin attempts to automatically create library wrapper modules for any "plain" JARs it finds.

I am rather afraid of making any changes to this complex logic. There is a unit test, but it also uses maven-dependency-tree, so there is no way to confirm that a rewrite preserves the same behavior (minus this bug). Probably safer to leave the code the way it is for now, especially since this bug only manifests itself in cases where Maven 2.x in fact produced the wrong classpath and you really ought to edit your POM to work around that problem anyway.

Might suffice to just ask for all the project's (transitive) dependencies, and use just Artifact.dependencyTrail to determine whether it is there via a module dep or not. The problem is that this algorithm would not emit the warnings that the current code does when encountering duplicate (or conflicting) dependencies. It is not yet clear to me whether these warnings are important in practice.

http://www.sonatype.com/people/2011/01/how-to-use-aether-in-maven-plugins/ is useful background in case Maven 2.x support could be dropped, but it may be premature for that.

Should check whether MNG-4982 is related, since this mentioned Batik.

The workaround is generally to explicitly specify, or exclude, whichever transitive dependency is treated differently by maven-dependency-tree vs. Aether.

The simplest fix would probably be to drop Maven 2 support.

MSHARED-167 fixed upstream, so could probably just switch to maven-dependency-tree-2.0 when it is released.

http://fisheye.codehaus.org/changelog/mojo/?cs=17295

this appears to have fixed the batik-js issue and all org.mozilla.javascript packages are now correctly found. However the sample build is still failing because of commmons-logging references to Log and LogFactory. I assume that's some sort of error in maven metadata (missing dependency on commons logging someplace), I was not able to find the dependency anywhere in the affected artifacts..

bumped minimal required version of maven to 2.2.0, that's what maven-dependency is using. Tested with maven 3.0.4