[EMAIL PROTECTED] wrote:
Steve Loughran <[EMAIL PROTECTED]> schrieb am 05.12.2006 14:51:52:
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!).
With MetaMake, something like that is possible but we (usually) don't do
it.
As you said, the key argument is: Even if it's stupid to run though a mine
field, sometimes, you *have* to (because someone is shooting at you).
A build tool should make the obvious things simple but it should not
prevent to solve corner cases. The current maven build system just cannot
cope with running "mvn deploy" for a part of the project so you can run
your tests in another.
The question is not if it's a stupid thing to do, the question is: If I
*have* to, what do I do? Currently, my solution is to revert to ant and
control maven from there
I use Ant+Ivy. I have my own complex state model. I just have to
struggle to keep everything locked down across 30 projects in 4
different repositories.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
