You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by John Casey <jd...@commonjava.org> on 2008/03/03 17:30:20 UTC
For Plugin Developers: Usage of ${plugin.artifacts} expression
I'd like to know how many people are using ${plugin.artifacts} in
their plugins.
I just came across a use case for plugin development, where the
developer needs access to the full dependency list for the plugin
using ${plugin.artifacts}. This is a problem because Maven currently
applies a filter to plugin-dependency artifacts during resolution, so
there isn't a classpath issue when invoking the mojo itself within
Maven.
We could do this a little differently, and preserve the $
{plugin.artifacts} expression for queries by plugin expressions.
Instead of filtering during artifact resolution to exclude the maven
core system artifacts, we could setup the PluginDescriptor.artifacts
collection with the raw closure of plugin dependency artifacts, then
filter this collection when we go to construct a new ClassRealm/
PlexusContainer (depending on which version of Maven you're using)
for that specific plugin. This way, the PluginDescriptor still
contains the unadulterated, unfiltered set of artifacts needed by
that plugin, and the container running the mojo still avoids
duplication with the core container.
This would mean that all of a sudden things like maven-plugin-api and
maven-project will start appearing in the result of $
{plugin.artifacts}, but it also means that it will contain commons-
cli. For those of you spawning new processes by building up a command
line invocation that contains commons-cli, this would mean you don't
have to re-add that manually in your mojo code. By the same token, it
will mean that you might want to watch out for maven-project and
maven-plugin-api (or, we could even strike a middle ground and filter
all org.apache.maven:* but I'm not sure that's a safe assumption to
make either).
Questions? Ideas? Thoughts at all?
-john
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
Re: For Plugin Developers: Usage of ${plugin.artifacts} expression
Posted by John Casey <jd...@commonjava.org>.
....All I can say is, OOPS!
I wasn't completely aware of this, but the plugin-classloader
construction logic changed in the trunk of maven from 2.0.x. It seems
that during the course of these changes the plugin manager stopped
managing the PluginDescriptor's artifacts collection as closely.
In fact, 2.0.x does what I proposed in this email, but 2.1 doesn't
(yet). I'm in the process of restoring this functionality now.
Please disregard my previous email, when I restore this functionality
the ${plugin.artifacts} expression should work as before.
-john
On Mar 3, 2008, at 11:30 AM, John Casey wrote:
> I'd like to know how many people are using ${plugin.artifacts} in
> their plugins.
>
> I just came across a use case for plugin development, where the
> developer needs access to the full dependency list for the plugin
> using ${plugin.artifacts}. This is a problem because Maven
> currently applies a filter to plugin-dependency artifacts during
> resolution, so there isn't a classpath issue when invoking the mojo
> itself within Maven.
>
> We could do this a little differently, and preserve the $
> {plugin.artifacts} expression for queries by plugin expressions.
> Instead of filtering during artifact resolution to exclude the
> maven core system artifacts, we could setup the
> PluginDescriptor.artifacts collection with the raw closure of
> plugin dependency artifacts, then filter this collection when we go
> to construct a new ClassRealm/PlexusContainer (depending on which
> version of Maven you're using) for that specific plugin. This way,
> the PluginDescriptor still contains the unadulterated, unfiltered
> set of artifacts needed by that plugin, and the container running
> the mojo still avoids duplication with the core container.
>
> This would mean that all of a sudden things like maven-plugin-api
> and maven-project will start appearing in the result of $
> {plugin.artifacts}, but it also means that it will contain commons-
> cli. For those of you spawning new processes by building up a
> command line invocation that contains commons-cli, this would mean
> you don't have to re-add that manually in your mojo code. By the
> same token, it will mean that you might want to watch out for maven-
> project and maven-plugin-api (or, we could even strike a middle
> ground and filter all org.apache.maven:* but I'm not sure that's a
> safe assumption to make either).
>
> Questions? Ideas? Thoughts at all?
>
> -john
>
> ---
> John Casey
> Committer and PMC Member, Apache Maven
> mail: jdcasey at commonjava dot org
> blog: http://www.ejlife.net/blogs/john
> rss: http://feeds.feedburner.com/ejlife/john
>
>
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
Re: For Plugin Developers: Usage of ${plugin.artifacts} expression
Posted by John Casey <jd...@commonjava.org>.
Yeah, I was mistaken. I'm working on clearing up the confusion, but
basically it got changed somewhere between 2.0.x branch and today in
trunk.
-john
On Mar 3, 2008, at 12:19 PM, Benjamin Bentmann wrote:
>> I'd like to know how many people are using ${plugin.artifacts} in
>> their plugins.
>
> One here, basically for a use-case similar to MANTRUN-41 on some in-
> house
> plugin.
>
>> This would mean that all of a sudden things like maven-plugin-api and
>> maven-project will start appearing in the result of $
>> {plugin.artifacts}
>
> Is there any spec around stating that Maven filters the plugin
> dependencies
> in this expression, i.e. an API contract that binds you to the
> existing
> behavior? If so, keeping the current behavior (at least for Maven
> 2.0.x)
> might be reasonable.
>
> Without a clear spec, developers might appreciate this change if
> they - like
> me - previously guessed/expected ${plugin.artifacts} would contain
> the full
> list and are tempted to call the current behavior say odd to
> prevent the
> b-word ;-)
>
>> By the same token, it
>> will mean that you might want to watch out for maven-project and
>> maven-plugin-api (or, we could even strike a middle ground and filter
>> all org.apache.maven:* but I'm not sure that's a safe assumption to
>> make either).
>
> Unless you are going to provide a customizable way of filtering
> ${plugin.artifacts}, I would favor the full list from Maven (don't
> try to be
> too smart) and have each plugin developer filter as needed since
> they know
> best what to exclude (if any). Besides, filtering artifacts is less
> hassle than adding them from scratch.
>
>
> Benjamin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
Re: For Plugin Developers: Usage of ${plugin.artifacts} expression
Posted by Benjamin Bentmann <be...@udo.edu>.
> I'd like to know how many people are using ${plugin.artifacts} in
> their plugins.
One here, basically for a use-case similar to MANTRUN-41 on some in-house
plugin.
> This would mean that all of a sudden things like maven-plugin-api and
> maven-project will start appearing in the result of $
> {plugin.artifacts}
Is there any spec around stating that Maven filters the plugin dependencies
in this expression, i.e. an API contract that binds you to the existing
behavior? If so, keeping the current behavior (at least for Maven 2.0.x)
might be reasonable.
Without a clear spec, developers might appreciate this change if they - like
me - previously guessed/expected ${plugin.artifacts} would contain the full
list and are tempted to call the current behavior say odd to prevent the
b-word ;-)
> By the same token, it
> will mean that you might want to watch out for maven-project and
> maven-plugin-api (or, we could even strike a middle ground and filter
> all org.apache.maven:* but I'm not sure that's a safe assumption to
> make either).
Unless you are going to provide a customizable way of filtering
${plugin.artifacts}, I would favor the full list from Maven (don't try to be
too smart) and have each plugin developer filter as needed since they know
best what to exclude (if any). Besides, filtering artifacts is less hassle
than adding them from scratch.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org