maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Casey <jdca...@commonjava.org>
Subject Re: For Plugin Developers: Usage of ${plugin.artifacts} expression
Date Mon, 03 Mar 2008 17:37:53 GMT
....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



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