I wrote a quick plugin that uses Guava via reflection (so I could try out different orderings in the build-time pom) and found the following:
Depending on maven-plugin-api, etc. with compile scope will bring all their transitive dependencies onto the plugin classpath (build and runtime) At runtime Maven’s DefaultArtifactFilterManager should filter out jars in the core+extensions (at least according to the class description) However while artifacts explicitly listed in DefaultArtifactFilterManager are excluded, their transitive dependencies like Guava are left on the plugin classpath The simplest solution to avoid this is to use provided scope when you depend on maven-plugin-api etc. so transitive dependencies aren’t automatically pulled in. Looking ahead I wonder if Maven should also use provided scope to in turn depend on container/spec jars? ie. in case people use compile scope in their plugin poms Finally should DefaultArtifactFilterManager consider transitive dependencies of excluded artifacts when filtering the plugin classpath? -- Cheers, Stuart On Friday, 7 November 2014 at 20:09, Mirko Friedenhagen wrote: > I always had to exclude sisu-guava when I wanted to use newer guava > versions in my plugins. > Regards Mirko > -- > http://illegalstateexception.blogspot.com/ > https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) > https://bitbucket.org/mfriedenhagen/ > > > On Fri, Nov 7, 2014 at 6:51 PM, Stuart McCulloch <mccu...@gmail.com > (mailto:mccu...@gmail.com)> wrote: > > That should work, or you could remove that transitive dependency from the > > build-time classpath by adding a dependency exclusion. > > > > At runtime the plugin realm is isolated from maven-core except for the > > specific packages exposed by DefaultClassRealmManager. > > > > -- > > Cheers, Stuart > > > > > > On Friday, 7 November 2014 at 17:13, Benson Margulies wrote: > > > > > See https://github.com/benson-basis/github-release-note-maven-plugin. > > > IntelliJ is sure that sisu-guava is in the class path. I am now trying > > > reordering the pom to see if it works to put real Guava at the head of > > > the line. > > > > > > dependency:tree: > > > > > > org.apache.maven:maven-plugin-api:jar:3.0.5:provided > > > [INFO] | +- org.apache.maven:maven-model:jar:3.0.5:provided > > > [INFO] | +- org.apache.maven:maven-artifact:jar:3.0.5:provided > > > [INFO] | \- org.sonatype.sisu:sisu-inject-plexus:jar:2.3.0:provided > > > [INFO] | \- org.sonatype.sisu:sisu-inject-bean:jar:2.3.0:provided > > > [INFO] | \- org.sonatype.sisu:sisu-guice:jar:no_aop:3.1.0:provided > > > [INFO] | \- org.sonatype.sisu:sisu-guava:jar:0.9.9:provided > > > > > > On Fri, Nov 7, 2014 at 12:08 PM, Benson Margulies <bimargul...@gmail.com > > > (mailto:bimargul...@gmail.com)> wrote: > > > > Oh, I thought this was old hat. Stand by ... > > > > > > > > On Fri, Nov 7, 2014 at 12:06 PM, Stuart McCulloch <mccu...@gmail.com > > > > (mailto:mccu...@gmail.com)> wrote: > > > > > AFAIK none of the Guava packages are exposed from maven core, so I’d > > > > > be interested to know more about where these types are leaking and > > > > > how to recreate this. > > > > > > > > > > -- > > > > > Cheers, Stuart > > > > > > > > > > > > > > > On Friday, 7 November 2014 at 16:59, Benson Margulies wrote: > > > > > > > > > > > Is there any possible way of insulating 3.0.x pipelines from the old > > > > > > version of Guava that leaks in with Sisu-guice? (Other than shading > > > > > > a > > > > > > current version of guice and using it?) > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > > (mailto:dev-unsubscr...@maven.apache.org) > > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > (mailto:dev-h...@maven.apache.org) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > (mailto:dev-unsubscr...@maven.apache.org) > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > (mailto:dev-h...@maven.apache.org) > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > (mailto:dev-unsubscr...@maven.apache.org) > For additional commands, e-mail: dev-h...@maven.apache.org > (mailto:dev-h...@maven.apache.org) > >
