That's not really the point. The point is that these behaviors
require exceptional logic to the main build process inside Maven.
They're a deviation of the normal once-per-project mojo, which is
geared to operate on the current project.
If you wanted to draw attention to something that doesn't fit the
'atypical' heading, I'd say that build introspection is a much better
target. Almost any sort of integration with Maven will need to be
able to extract this sort of information, and forcing a build to get
that information is a bad way to go.
If you really want to spend the time, and have a better title, feel
free to rename the document. I have no problems with that; I'm more
concerned with solving the problems I talk about in the document's
content.
-john
On Feb 13, 2008, at 6:52 PM, Dan Fabulich wrote:
John Casey wrote:
I'm trying to document some of the design problems with sort of
exotic plugin use cases, things like aggregation and use of $
{reactorProjects}, that we're running into under the current
setup. I have proposals to address most of the issues, but I'd
love to hear what you would propose...or even tell me about plugin-
design issues that I haven't thought of.
This may be quibbling, but it seems weird to me that aggregation
would be an atypical case. IMO, almost every reporting plugin
needs to do aggregation (or at least be able to do it).
checkstyle, clover, docck, javadoc, jxr, pmd, surefire-report all
need aggregation somehow or other.
-Dan
---------------------------------------------------------------------
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
