Brett Porter wrote:
This reply grabs bits from everywhere and summarises.
John Casey wrote:
Hi,
I'd like to add pre/post phases for all of the major lifecycle phases
that don't already have it.
For the record, I'm against this as the solution based on the thread so
far. Some basic reasons before going into details:
1) pre/post is wrong in general, as pre-two = post-one. So we should
have one phase between, but there we need an appropriate name. Likely
this is something sensible and becomes a new lifecycle phase - just like
we have now. Then we later discover that needs pre/post, and so on :) I
think this really degrades to prereqs and pre/post goals that we had in
m1/pre-alpha m2, which we eliminated for good reasons.
The pre/post thing I believe is really more grouping the execution of
your mojo with the appropriate phase. For example post processing
classes versus pre generating test sources.
I also don't think that this will degrade into m1 because we do have the
lifecycle.The default lifecycle and mojos we have bound to the phases in
that lifecycle should be compelling enough and satisfactory for 95% of
whatever you need to do. We already have structure where none existed
before in m1.
If we don't allow some flexibility here, whether pre/post phase or a
single mediating phase, is forcing users to use workarounds and put
things in seemingly unnatural places and making them wait for future
releases to support what they want. I am, of course, all for standards
but to leave no give I now think is unacceptable. I don't think it will
become commonplace to deviate from the default lifecycle because it's
just not convenient.
I would rather give people a little wiggle room there and incorporate
the feedback in subsequent releases instead of forcing users to wait for
the extensions simply because this is better for the user. We laid down
a solid framework and put the safety on, if the user wants to take the
safety off and see what the barrel tastes like then they take that risk.
I don't see this becoming common place but the flexibility will allow
people to uses releases and get out of jam if necessary. I don't see any
downside here other then us having to write a little more doco on why
writing your own lifecycle is a bad idea.
2) Some of this discussion around rearranging the lifecycle defeats the
actual purpose of the lifecycle in the first place
I agree, reordering I would say is a bad idea.
It doesn't seem like a good idea to continue addressing this problem an
issue at a time in successive Maven releases.
Actually, I think we should. That means we carefully assess each one and
take care in adding it.
I think we can let users some freedom and put the onus on us to filter
out the salient use-cases put forward and integrate those suggestions
into the default lifecycle. It just puts the flexibility on the users
side of the equation. I think we may slowly approach covering 99% of
lifecycle requirements but that's going to take some time and the
inflexibility does the user a disservice.
I'd like to get this into 2.0.3, since it affects some work I'm doing
for a client.
Since you have a workaround, I'd prefer we look at the proper solution
for 2.1. I had great reservations about allowing this for integration
tests in 2.0.2.
I think the approach of putting in the mediating phase(s) for 2.0.3|4 is
good if we take the approach of integrating those ideas in subsequently.
Users can stuff themselves now if they want, we aren't going to prevent
that by allowing some alternative nomenclature which is what pre/post is
essentially. I think that the pre/post hooks are a natural way for
extension given the solid foundation we've given in the form of the
default lifecycle. I'm getting soft in my old age :-)
The rest I think are concerns for 2.1 and can go in the wiki. Please
make sure it goes into the wiki or it will get lost in the mailing list
shuffle.
[snip]
- Brett
jvz.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
