Jason van Zyl wrote: > Brett Porter wrote: > >> -1 to generic pre/post phases. For one, there's no difference between >> pre-process-classes and post-compile. > > Maybe that indicates that the process-classes is really a decoration > for the compile phase. We have several places in the lifecycle where > the same argument applies. Are there phases that are more concrete > then others i.e. like compile? Do we have them all? I don't know. We > can easily change the lifecycle phases like we are proposing now but > will we be continually doing that in the future. You're right - and I think what we actually have now is a set of concrete phases, and one phase in between that is effectively the mergere of pre/post of the proceeding and current.
I doubt we'd be changing anything continually, and once something is there we certainly can't remove it. > > So far it only seems to be the testing scenerios that are driving this > discussion. Has there ever been anything else that has been mentioned > which would require a change to the lifecycle? Don't get me wrong, I > love the concrete lifecycle. I just don't want it to be a continual > limitation either. I think the only other use case I've heard is generating resources that generate sources. We knew the testing capacity was limited, but I don't recall hearing much outside of that. > > It would just be a simpler way to bind mojos as decorations in the POM > as opposed to creating a lifecycle file. The separate lifecycle file is more about completely customising it (even changing the order, dangerous though I'm sure that is). If we just do pre/post, won't the next point be that pre-pre-compile is needed? - Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
