being able to bind to the front and back of a lifecycle would be
absolutely
splendid
+1. A simple event system which fired build events to registered
listeners (plugins could register these) would go a long way. Example
events could be:
* Build Started
* Phase Started
* Goal Started
* Goal Ended
* Phase Ended
* Build Failed
* Build Complete
Brian E Fox wrote:
Yes it's binding the aggregator with @execute to a lifecycle that
is the
problem. There's nothing wrong with aggregators that are meant to
perform
some action from the CLI. The trouble is that everyone ends up
making two
goals, one @aggregator and one xxx-only goal that is without the
aggregator.
I know of too many instances where someone bound an aggregator
executor
goal
to a lifecycle and ended up with n*n-1 recursive builds or other
crazy
behavior.
What I think we need is an annotation that says "execute up to this
phase
only if it hasn't already run" essentially a minimum phase execution.
There also needs to be a way to attach a plugin to execute before the
lifecycle to influence things like inject dependencies and we also
need a
way to bind to the very end of a build for cleanup or metric
collection
types of things.
On 12/5/08 7:59 PM, "Brett Porter" <[EMAIL PROTECTED]> wrote:
On 06/12/2008, at 9:37 AM, Brian Fox wrote:
There's nothing presumptive about the fact that it HAS been
deprecated in trunk for quite some time now. (since it was still
called 2.1-snap)
Ok, you're right, when binding to the lifecycle (which admittedly we
are talking about here), though not generally.
Aren't the source of these problems when it is used in conjunction
with @execute? (Which is probably the more problematic annotation, I
was never happy with the way that was done).
The aggregator is full of problems and usually leads to recursive
builds when you bind it to the lifecycle. A complely new concept is
needed to handle this use case.
But doesn't yet exist, so perhaps a warning is more appropriate
than a
deprecation at this point. It does still work for the limited use
cases it was designed for (such as the Nick is referring to).
Cheers,
Brett
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/What-will-replace-the-%40aggregator-MOJO-configuration--tp20825520p20873221.html
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
