....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
