Jason van Zyl wrote:
On 4 Dec 06, at 9:59 AM 4 Dec 06, Ralph Goers wrote:
Richard,
I love this idea and hate it at the same time. The idea of using
numbers, as I'm sure has been pointed out before, just seems awful.
But I understand what you are driving at. If there was a way to
register named phases with the numbers that would be better.
OTOH, wouldn't it be better just to allow the list of phases to be
specified in settings.xml?
Ralph
You can always make your own lifecycle, which is not that hard if you
really need it. We will only expand the lifecycle as the need requires.
It will never become a mess of spaghetti like Maven 1.x. To allow free
form to accommodate the ever shrinking number of cases we can't handle
is just not worth it. The standard lifecycle then disappears and Maven
becomes a very hard to explain. It one of the fundamental differences
between Maven and everything else and though we run up against some
limitations it is one of Maven's most powerful attributes.
The strength of standardised 'states', as that is what this really is,
is that you can be sure that even third party products can be moved into
the same state. This becomes important when your build tree includes
symlinks to four different repositories and something above to
co-ordinate the lot.
The weakness is that someone, somewhere, has to lay down what those
states are. And what works for simple
ready-to-compile->compiled->packaged->tested->published lifecycle gets
complex if you have to do silly things like throw the SOAP stack at the
compiled app source to generate the WSDL for the test run, or create a
test JAR that is itself signed and tested (meta testing, yes!).
Adding more stages is certainly one solution. The other is to say 'our
build should be refactored into more tractable components, each with a
simpler lifecycle and inter-dependencies'.
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
