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 <[email protected]> > 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 <[email protected]> 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: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
