Details
-
Type:
Improvement
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 3.2
-
Fix Version/s: 3.2
-
Component/s: None
-
Labels:None
-
Testcase included:yes
-
Number of attachments :
Description
Plugin should print out more descriptive information, when there is a problem in dependencies. In simple attached example, I got error without any information, what happened:
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 2 source files to P:\test\nbm-plugin-error\module1\target\class
es
[INFO] [nbm:manifest {execution: default-manifest}]
[INFO] NBM Plugin generates manifest
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] See above for failures in runtime NebBeans dependencies verification.
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 9 seconds
And with -e switch:
[INFO] Trace
org.apache.maven.BuildFailureException: See above for failures in runtime NebBeans dependencies verification.
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:699)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41)
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.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoFailureException: See above for failuresin runtime NebBeans dependencies verification.
at org.codehaus.mojo.nbm.NetbeansManifestUpdateMojo.checkModuleClassPath(NetbeansManifestUpdateMojo.java:585)
at org.codehaus.mojo.nbm.NetbeansManifestUpdateMojo.execute(NetbeansManifestUpdateMojo.java:432)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
... 17 more
[INFO] ------------------------------------------------------------------------
It happened in case, when there are more dependencies, not listed, but are not from transitional module or are not private.
See lines NetbeansManifestUpdateMojo.java:552 - 587.
Simple testcase attached.
Attachments
-
$i18n.getText("admin.common.words.hide")
-
-
nbm-plugin-error/libs/pom.xml
-
nbm-plugin-error/module1/pom.xml
-
nbm-plugin-error/module1/.../Installer.java
-
nbm-plugin-error/module1/.../URLtest.java
-
nbm-plugin-error/module1/.../nbm/MANIFEST.MF
-
nbm-plugin-error/parent/pom.xml
-
nbm-plugin-error/pom.xml
-
nbm-plugin-error/util/pom.xml
-
nbm-plugin-error/util/src/.../util/Util.java
-
-
this is indeed a complex problem.
1. class StrBuilder is used in the module1 codebase
2. StrBuilder is not explicitly imported, but is a result type of a method call, from module util.
3. the module util is transitive and as such should be reported and made direct dependency by the user.
4. but it's not reported because the commons-lang dependency is duplicated as direct dependency in module1. If we comment out that dependency, we will get the proper error.
5. the commons-lang dependency in actually an OSGI bundle and is therefore not currently recognized as module's library, but as module dependency.
I'm wondering we we would get a proper error if the jar were not an OSGi bundle. This is actually the scenario I feared when adding Osgi dependency support. What if someone wants to add a bundle dep as plain library jar? Can we actually differentiate these 2 cases?