Re: dependency plugin strangeness
The crucial detail was omitted... what version of Maven? I suspect it could be a transitive dependency with system scope causing a bug of some sort. Most likely if you switch to a different version of Maven the command will work... in which case you might be able to construct a test case to prove a regression. Touchstone versions of Maven to try are: 2.2.1, 3.0.4/3.0.5 and 3.1.1 If you see the error on all three then it is something different... but still an important data point. More of the stack trace would help... ideally include a line or two above and below... there is often crucial details therein... if you need to hide GAV details, change the groupId's to something gibberish, e.g. com.foobar:foo-manchu:1.0-SNAPSHOT and other dummy GAVs On 28 January 2014 22:55, Lyons, Roy roy.ly...@cmegroup.com wrote: So, I tried my google-fu first - and in general my google-fu is very very strong... I've been fighting with this multi-module plan for some time now with the developer who is reporting the issue to me. The issue manifested itself as part of a Sonar failure... the funny thing is, that the failure was on a dependenct tree resolution that Sonar was doing - so I had him try the dependency plugin and perform a dependency:tree dependency tree failed us... well, it probably isn't dependency plugin's fault but I am at a loss as to what it is really dying on or why. I would absolutely love it if someone saw this and said Oh yeah, I know that issue. Its a real pain. They have XXX defined incorrectly in their multimodule build so the dependency plugin is in a circular dependency loop (or something like that). I have no idea if its a dependency loop, was just an example. I can't share the poms because its all proprietary closed source stuff (and I have to be careful about what is shared). If this means that I dont have enough info to help, I can live with that - and will continue to plow forwards... I just wanted to see if theres someone on the list who knows exactly what I should be looking for to help shorten my investigation time. Here's an example of what dependency:tree is complaining about. mvn dependency:tree -Dverbose=true -DoutputFile=dependencies.txt -e -X urls[38] = file:/C:/Users/thisguysuserid/.m2/repository/commons-collections/commons-collections/3.2.1/commons-collections-3.2.1.jar Number of foreign imports: 1 import: Entry[import from realm ClassRealm[maven.api, parent: null]] - at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:139) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 19 more Caused by: org.apache.maven.plugin.PluginContainerException: An API incompatibility was encountered while executing org.apache.maven.plugins:maven-dependency-plugin:2.8:tree: java.lang.AbstractMethodError: org.apache.maven.shared.dependency.tree.DependencyTreeResolutionListener.manageArtifactSystemPath(Lorg/apache/maven/artifact/Artifact;Lorg/apache/maven/artifact/Artifact;)V - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: dependency plugin strangeness
Hi, I have already seen such error. It is caused by the combination of a managed dependency (through dependencyManagement) defining a dependency with system scope + Maven 3 + Sonar. The same with Maven 2.2.1 should work. Though, I have never seen it directly in a dependency:tree execution; only through a sonar analysis. On my side, I got rid of the system scope usages. Vincent 2014-01-29 Stephen Connolly stephen.alan.conno...@gmail.com The crucial detail was omitted... what version of Maven? I suspect it could be a transitive dependency with system scope causing a bug of some sort. Most likely if you switch to a different version of Maven the command will work... in which case you might be able to construct a test case to prove a regression. Touchstone versions of Maven to try are: 2.2.1, 3.0.4/3.0.5 and 3.1.1 If you see the error on all three then it is something different... but still an important data point. More of the stack trace would help... ideally include a line or two above and below... there is often crucial details therein... if you need to hide GAV details, change the groupId's to something gibberish, e.g. com.foobar:foo-manchu:1.0-SNAPSHOT and other dummy GAVs On 28 January 2014 22:55, Lyons, Roy roy.ly...@cmegroup.com wrote: So, I tried my google-fu first - and in general my google-fu is very very strong... I've been fighting with this multi-module plan for some time now with the developer who is reporting the issue to me. The issue manifested itself as part of a Sonar failure... the funny thing is, that the failure was on a dependenct tree resolution that Sonar was doing - so I had him try the dependency plugin and perform a dependency:tree dependency tree failed us... well, it probably isn't dependency plugin's fault but I am at a loss as to what it is really dying on or why. I would absolutely love it if someone saw this and said Oh yeah, I know that issue. Its a real pain. They have XXX defined incorrectly in their multimodule build so the dependency plugin is in a circular dependency loop (or something like that). I have no idea if its a dependency loop, was just an example. I can't share the poms because its all proprietary closed source stuff (and I have to be careful about what is shared). If this means that I dont have enough info to help, I can live with that - and will continue to plow forwards... I just wanted to see if theres someone on the list who knows exactly what I should be looking for to help shorten my investigation time. Here's an example of what dependency:tree is complaining about. mvn dependency:tree -Dverbose=true -DoutputFile=dependencies.txt -e -X urls[38] = file:/C:/Users/thisguysuserid/.m2/repository/commons-collections/commons-collections/3.2.1/commons-collections-3.2.1.jar Number of foreign imports: 1 import: Entry[import from realm ClassRealm[maven.api, parent: null]] - at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:139) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 19 more Caused by: org.apache.maven.plugin.PluginContainerException: An API incompatibility was encountered while executing org.apache.maven.plugins:maven-dependency-plugin:2.8:tree: java.lang.AbstractMethodError: org.apache.maven.shared.dependency.tree.DependencyTreeResolutionListener.manageArtifactSystemPath(Lorg/apache/maven/artifact/Artifact;Lorg/apache/maven/artifact/Artifact;)V - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: dependency plugin strangeness
After Stephen mentioned trying different versions, I had the developer try out maven 2.2.1. I was about to report back that this worked and how strange it was -- but before sending I saw this email from Vincent. I'll pass along the system scope issue - perhaps that is the nail in the coffin. We reverted with 2.2.1, with instructions to work on making it 3.x compliant in the background. Thank you for all the input on this issue. It is very much appreciated. Thanks, Roy On 1/29/14 12:33 PM, Vincent Latombe vincent.lato...@gmail.com wrote: Hi, I have already seen such error. It is caused by the combination of a managed dependency (through dependencyManagement) defining a dependency with system scope + Maven 3 + Sonar. The same with Maven 2.2.1 should work. Though, I have never seen it directly in a dependency:tree execution; only through a sonar analysis. On my side, I got rid of the system scope usages. Vincent 2014-01-29 Stephen Connolly stephen.alan.conno...@gmail.com The crucial detail was omitted... what version of Maven? I suspect it could be a transitive dependency with system scope causing a bug of some sort. Most likely if you switch to a different version of Maven the command will work... in which case you might be able to construct a test case to prove a regression. Touchstone versions of Maven to try are: 2.2.1, 3.0.4/3.0.5 and 3.1.1 If you see the error on all three then it is something different... but still an important data point. More of the stack trace would help... ideally include a line or two above and below... there is often crucial details therein... if you need to hide GAV details, change the groupId's to something gibberish, e.g. com.foobar:foo-manchu:1.0-SNAPSHOT and other dummy GAVs On 28 January 2014 22:55, Lyons, Roy roy.ly...@cmegroup.com wrote: So, I tried my google-fu first - and in general my google-fu is very very strong... I've been fighting with this multi-module plan for some time now with the developer who is reporting the issue to me. The issue manifested itself as part of a Sonar failure... the funny thing is, that the failure was on a dependenct tree resolution that Sonar was doing - so I had him try the dependency plugin and perform a dependency:tree dependency tree failed us... well, it probably isn't dependency plugin's fault but I am at a loss as to what it is really dying on or why. I would absolutely love it if someone saw this and said Oh yeah, I know that issue. Its a real pain. They have XXX defined incorrectly in their multimodule build so the dependency plugin is in a circular dependency loop (or something like that). I have no idea if its a dependency loop, was just an example. I can't share the poms because its all proprietary closed source stuff (and I have to be careful about what is shared). If this means that I dont have enough info to help, I can live with that - and will continue to plow forwards... I just wanted to see if theres someone on the list who knows exactly what I should be looking for to help shorten my investigation time. Here's an example of what dependency:tree is complaining about. mvn dependency:tree -Dverbose=true -DoutputFile=dependencies.txt -e -X urls[38] = file:/C:/Users/thisguysuserid/.m2/repository/commons-collections/commons- collections/3.2.1/commons-collections-3.2.1.jar Number of foreign imports: 1 import: Entry[import from realm ClassRealm[maven.api, parent: null]] - at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuil dPluginManager.java:139) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.jav a:209) ... 19 more Caused by: org.apache.maven.plugin.PluginContainerException: An API incompatibility was encountered while executing org.apache.maven.plugins:maven-dependency-plugin:2.8:tree: java.lang.AbstractMethodError: org.apache.maven.shared.dependency.tree.DependencyTreeResolutionListener. manageArtifactSystemPath(Lorg/apache/maven/artifact/Artifact;Lorg/apache/ maven/artifact/Artifact;)V - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
dependency plugin strangeness
So, I tried my google-fu first - and in general my google-fu is very very strong... I've been fighting with this multi-module plan for some time now with the developer who is reporting the issue to me. The issue manifested itself as part of a Sonar failure... the funny thing is, that the failure was on a dependenct tree resolution that Sonar was doing - so I had him try the dependency plugin and perform a dependency:tree dependency tree failed us... well, it probably isn't dependency plugin's fault but I am at a loss as to what it is really dying on or why. I would absolutely love it if someone saw this and said Oh yeah, I know that issue. Its a real pain. They have XXX defined incorrectly in their multimodule build so the dependency plugin is in a circular dependency loop (or something like that). I have no idea if its a dependency loop, was just an example. I can't share the poms because its all proprietary closed source stuff (and I have to be careful about what is shared). If this means that I dont have enough info to help, I can live with that - and will continue to plow forwards... I just wanted to see if theres someone on the list who knows exactly what I should be looking for to help shorten my investigation time. Here's an example of what dependency:tree is complaining about. mvn dependency:tree -Dverbose=true -DoutputFile=dependencies.txt -e -X urls[38] = file:/C:/Users/thisguysuserid/.m2/repository/commons-collections/commons-collections/3.2.1/commons-collections-3.2.1.jar Number of foreign imports: 1 import: Entry[import from realm ClassRealm[maven.api, parent: null]] - at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:139) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 19 more Caused by: org.apache.maven.plugin.PluginContainerException: An API incompatibility was encountered while executing org.apache.maven.plugins:maven-dependency-plugin:2.8:tree: java.lang.AbstractMethodError: org.apache.maven.shared.dependency.tree.DependencyTreeResolutionListener.manageArtifactSystemPath(Lorg/apache/maven/artifact/Artifact;Lorg/apache/maven/artifact/Artifact;)V - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: dependency plugin strangeness
Hi Roy, Can you use a bisect-style debugging approach? Remove half of the modules from the build and run dependency:tree again. If it works, add half back in again; if not, remove half of what remains. Etc. Then at least you might isolate the problem a bit more. It also might make it easier to create a minimal test case for bug reporting purposes. Regards, Curtis On Jan 28, 2014 4:56 PM, Lyons, Roy roy.ly...@cmegroup.com wrote: So, I tried my google-fu first - and in general my google-fu is very very strong... I've been fighting with this multi-module plan for some time now with the developer who is reporting the issue to me. The issue manifested itself as part of a Sonar failure... the funny thing is, that the failure was on a dependenct tree resolution that Sonar was doing - so I had him try the dependency plugin and perform a dependency:tree dependency tree failed us... well, it probably isn't dependency plugin's fault but I am at a loss as to what it is really dying on or why. I would absolutely love it if someone saw this and said Oh yeah, I know that issue. Its a real pain. They have XXX defined incorrectly in their multimodule build so the dependency plugin is in a circular dependency loop (or something like that). I have no idea if its a dependency loop, was just an example. I can't share the poms because its all proprietary closed source stuff (and I have to be careful about what is shared). If this means that I dont have enough info to help, I can live with that - and will continue to plow forwards... I just wanted to see if theres someone on the list who knows exactly what I should be looking for to help shorten my investigation time. Here's an example of what dependency:tree is complaining about. mvn dependency:tree -Dverbose=true -DoutputFile=dependencies.txt -e -X urls[38] = file:/C:/Users/thisguysuserid/.m2/repository/commons-collections/commons-collections/3.2.1/commons-collections-3.2.1.jar Number of foreign imports: 1 import: Entry[import from realm ClassRealm[maven.api, parent: null]] - at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:139) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 19 more Caused by: org.apache.maven.plugin.PluginContainerException: An API incompatibility was encountered while executing org.apache.maven.plugins:maven-dependency-plugin:2.8:tree: java.lang.AbstractMethodError: org.apache.maven.shared.dependency.tree.DependencyTreeResolutionListener.manageArtifactSystemPath(Lorg/apache/maven/artifact/Artifact;Lorg/apache/maven/artifact/Artifact;)V - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
