On 07/12/2008, at 2:06 AM, 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.
Agreed. How do we pursue these ideas? Wiki?
Not sure how they fit in with the lifecycle refactoring of 3.0 or if
there's a bunch of these we could get happening sooner.
- Brett
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]