Mojo's NetBeans Module Maven Plugin
  1. Mojo's NetBeans Module Maven Plugin
  2. MNBMODULE-102

Transitive dependencies incorrectly processed in Maven 3

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 3.3
    • Fix Version/s: 3.8
    • Labels:
      None
    • Environment:
      Fedora Linux 13 64 bit, Windows XP SP3, JDK 6 update 21
    • Testcase included:
      yes
    • Number of attachments :
      1

      Description

      We have found this problem, when we tried to test Maven 3.0 with our project. With an older version we were able to compile the whole project without any problem. With a new version we have a problem with nbm-maven-plugin. We could see this :

      [ERROR] Failed to execute goal org.codehaus.mojo:nbm-maven-plugin:3.3:manifest (default-cli) on project netrad.client.gui.module.core: See above for failures in runtime NetBeans dependencies verification. 
      
      There is a little help that we should have a look above but unfortunately there isn't any information why the building process failed. If we tried to run maven with -X option, we could see :
      org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:nbm-maven-plugin:3.3:manifest (default-cli) on project netrad.client.gui.module.core: See above for failures in runtime NetBeans dependencies verification.
          at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:199)
          at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
          at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140)
          at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
          at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
          at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
          at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
          at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:314)
          at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:151)
          at org.apache.maven.cli.MavenCli.execute(MavenCli.java:445)
          at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:168)
          at org.apache.maven.cli.MavenCli.main(MavenCli.java:132)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at java.lang.reflect.Method.invoke(Method.java:597)
          at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
          at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
          at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
          at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
      Caused by: org.apache.maven.plugin.MojoFailureException: See above for failures in runtime NetBeans dependencies verification.
          at org.codehaus.mojo.nbm.NetbeansManifestUpdateMojo.checkModuleClassPath(NetbeansManifestUpdateMojo.java:625)
          at org.codehaus.mojo.nbm.NetbeansManifestUpdateMojo.execute(NetbeansManifestUpdateMojo.java:447)
          at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
          at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195)
          ... 19 more 

      I have prepared a demo project which shows this problem. Also I have found out which dependency in pom.xml causes this problem. If I remove "test2.nvc.widget" dependency from the module-core, everything is ok.

        Issue Links

          Activity

          Hide
          Jesse Glick added a comment -

          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.

          Show
          Jesse Glick added a comment - 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.
          Hide
          Jesse Glick added a comment -

          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.

          Show
          Jesse Glick added a comment - 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.
          Hide
          Jesse Glick added a comment -

          Workaround:

                          <exclusion>
                              <groupId>org.apache.xmlgraphics</groupId>
                              <artifactId>batik-js</artifactId>
                          </exclusion>
          
          Show
          Jesse Glick added a comment - Workaround: <exclusion> <groupId>org.apache.xmlgraphics</groupId> <artifactId>batik-js</artifactId> </exclusion>
          Hide
          Jesse Glick added a comment -

          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.

          Show
          Jesse Glick added a comment - 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.
          Hide
          Jesse Glick added a comment -

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

          Show
          Jesse Glick added a comment - The difference is that in Maven 2, MavenProject.getRuntimeArtifacts also incorrectly omits batik-js, and some set subtraction is going on.
          Hide
          Jakub Herkel added a comment -

          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?

          Show
          Jakub Herkel added a comment - 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?
          Hide
          Jesse Glick added a comment -

          You can indeed use Visual Library as a plain JAR. But if you want the JAR that uses Visual Library to be used in a NB app, then it must also be packaged as a module. Just use nbm packaging and you can simply use the secondary jar artifact from the module in a non-NB app.

          Show
          Jesse Glick added a comment - You can indeed use Visual Library as a plain JAR. But if you want the JAR that uses Visual Library to be used in a NB app, then it must also be packaged as a module. Just use nbm packaging and you can simply use the secondary jar artifact from the module in a non-NB app.
          Hide
          Jesse Glick added a comment -

          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.

          Show
          Jesse Glick added a comment - 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.
          Hide
          Jesse Glick added a comment -

          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.

          Show
          Jesse Glick added a comment - 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.
          Hide
          Jesse Glick added a comment -

          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.

          Show
          Jesse Glick added a comment - 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.
          Hide
          Jesse Glick added a comment -

          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.

          Show
          Jesse Glick added a comment - 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.
          Hide
          Jesse Glick added a comment -

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

          Show
          Jesse Glick added a comment - Should check whether MNG-4982 is related, since this mentioned Batik.
          Hide
          Jesse Glick added a comment -

          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.

          Show
          Jesse Glick added a comment - 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.
          Hide
          Jesse Glick added a comment -

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

          Show
          Jesse Glick added a comment - MSHARED-167 fixed upstream, so could probably just switch to maven-dependency-tree-2.0 when it is released.
          Hide
          Milos Kleint added a comment -

          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

          Show
          Milos Kleint added a comment - 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

            People

            • Assignee:
              Milos Kleint
              Reporter:
              Jakub Herkel
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: