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.
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 other phases are
already granular enough. "It can't hurt" is probably not a good
justification :)
As with the lifecycle specification, not something encouraged but allows
someone in a bind to do something they need to do.
FWIW, I'm pretty sure you can specify your own
lifecycle now, though it remains discouraged and undocumented.
It would just be a simpler way to bind mojos as decorations in the POM
as opposed to creating a lifecycle file.
+1 to renaming the maven-it-plugin to the maven-plugin-it-plugin or
something similar. Or even the maven-embedder-plugin if it is that generic.
Cheers,
Brett
Vincent Massol wrote:
Hi there,
I'd like to continue the discussion about integration testing (see
http://docs.codehaus.org/display/MAVEN/Testing+Strategies). Here are some
topics on which I'd like to get your opinion:
1) Need for a pre/post phase to integration-test. See
http://jira.codehaus.org/browse/MNG-1880.
I guess this could be implemented very quickly. Isn't it just a matter of
adding 2 new phases in components.xml?
Do we all agree on the need for this?
2) I think there are use cases when we want to have the integration tests in
the same module as what they are testing. For example, take the case of an
ejb project. I think the project could have both unit tests and integration
tests in the same module. Functional tests is another matter and I'd usually
see them in a separate module altogether (as they usually require several
modules to be built).
ejb/
src/
main/
test/
java/ (unit tests - shouldn't be called java really)
it/ (integration tests)
I have a use case for the daytrader build where I need to do this. I'd like
to have some it tests next to some unit tests. The reason I want them in the
same module is because I want to have 1 or 2 it tests to act as a quick
proof that the ejb code works. It's not meant to replace functional tests
which I'm also doing but in some other module.
I don't think the surefire plugin support this right now. The problem is
that it's using configuration elements defined outside of the <plugin>
section in the pom so I don't think it's currently possible to have several
executions of it with different configurations.
Another option is to have an it plugin which is basically the same as the
surefire plugin but bound at different phases and using different
configuration elements.
Which solution do we want?
Note: the current it plugin is probably not correctly named as it makes
sense only for performing integration tests for m2 plugin.
WDYT?
Thanks
-Vincent
___________________________________________________________________________
Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.
Téléchargez sur http://fr.messenger.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
jason at maven.org
http://maven.apache.org
Simplex sigillum veri. (Simplicity is the seal of truth.)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
