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
