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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
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
