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 > >
