maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <>
Subject Re: dependency plugin strangeness
Date Wed, 29 Jan 2014 11:01:51 GMT
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

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 <> 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(
>         at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(
>         ... 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:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message