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]

Reply via email to