Hmm. It seems to me that, somehow, if I specify maven-plugin-api as a provided dependency, I should not be getting anything except the defined, public, plugin API into the compile classpath. I suppose that translates into Stuart's suggestion about the scope of its inclusion of its dependencies.
On Fri, Nov 7, 2014 at 5:53 PM, Stuart McCulloch <[email protected]> wrote: > 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 <[email protected] >> (mailto:[email protected])> 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 <[email protected] >> > > (mailto:[email protected])> wrote: >> > > > Oh, I thought this was old hat. Stand by ... >> > > > >> > > > On Fri, Nov 7, 2014 at 12:06 PM, Stuart McCulloch <[email protected] >> > > > (mailto:[email protected])> 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: [email protected] >> > > > > > (mailto:[email protected]) >> > > > > > For additional commands, e-mail: [email protected] >> > > > > > (mailto:[email protected]) >> > > > > > >> > > > > >> > > > > >> > > > >> > > > >> > > >> > > >> > > >> > > --------------------------------------------------------------------- >> > > To unsubscribe, e-mail: [email protected] >> > > (mailto:[email protected]) >> > > For additional commands, e-mail: [email protected] >> > > (mailto:[email protected]) >> > > >> > >> > >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> (mailto:[email protected]) >> For additional commands, e-mail: [email protected] >> (mailto:[email protected]) >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
