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
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 ru
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
Github user adangel closed the pull request at:
https://github.com/apache/maven-plugins/pull/30
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
Hi,
The vote has passed with the following result:
+1 (binding): Karl, Olivier, Kristian
I will promote the artifacts to the central repo and trouble with the docs.
Kristian
2014-11-05 23:32 GMT+01:00 Olivier Lamy :
> +1
>
> On 5 November 2014 03:08, Kristian Rosenvold wrote:
>> Hi,
>>
>> We
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 Novem
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
Oh, I thought this was old hat. Stand by ...
On Fri, Nov 7, 2014 at 12:06 PM, Stuart McCulloch 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
>
>
>
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 pipe
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.apa
Github user asfgit closed the pull request at:
https://github.com/apache/maven-surefire/pull/66
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
11 matches
Mail list logo
