maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Casey <>
Subject For Plugin Developers: Usage of ${plugin.artifacts} expression
Date Mon, 03 Mar 2008 16:30:20 GMT
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  

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 Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message