Hello, if I remember right, I had problems because the enforcer duplicate class rule was complaining. I think an artifact called API should not have or at least expose any dependencies not found in it's contracts, so maybe that is the problem.
Regards Mirko -- Sent from my mobile On Nov 7, 2014 11:55 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]) > > > > > > >
