OK, maven-surefire-plugin is well known to everyone
it's lesser-known sister is failsafe-maven-plugin failsafe was written (by me) to solve some of the issues of running integration tests with the maven lifecycle. the lifecycle has a number of phases * some crappy phases * test * some more crappy phases * pre-integration-test * integration-test * post-integration-test * verify * yet more crappy phases surefire binds to the test phase, and by default will fail your build at the test phase if any of the tests it runs fail. That is all well and good when running unit tests... when we want to run integration tests, we usually want to set up some environment which we are integrating with, e.g. start a jetty server and deploy the current application to that server, or start a database server (e.g. derby) and configure the data source, etc so we use the pre-integration-test phase to do this set-up, and we tidy-up in the post-integration-test phase... when our pre-integration-test stuff is all running in the maven JVM, everything is hunky-dory (http://www.taytohunkydorys.ie/brands/hunky_dorys.asp). we bind a second execution of surefire:test to the integration-test phase and when/if the tests fail, the JVM gets killed and our integration test environment gets destroyed... however, if our pre-integration-test stuff affects external processes, we are stuck because we have no way to tidy-up in the post-integration-test phase (BTW, IMHO nobody should ever run "mvn integration-test". 1. it's too long to type, and 2, you reallly want to run "mvn verify" as that will give the post-integration-test phase a chance to run) failsafe solves the issue by decoupling failing the build from running the tests, failsafe:integration-test never fails the build, that is left up to failsafe:verify, and thus (as long as you never invoke a phase in the range [pre-integration-test,post-integration-test]) your tidy-up plugin configuration will always run. So, as part of rolling the 2.5 release of surefire, I was looking into merging the two plugins... My initial idea was to just move the mojo's into m-surefire-p as is, thus m-s-p would have three mojos: test, integration-test and verify However, there are advantages to keeping them as separate plugins: * Use case 1: Ignore Unit Test Failures and run the integration tests (I know Bob has broken the unit tests for that new feature he is writing, but I want to check I have not created a regression in the stuff I'm working on) - the verify mojo parses the xml result files to see if any tests failed. If we use the same plugin, we should really use the same directory (e.g. surefire-reports) It does not make sense for surefire to have one goal report to surefire-reports and the other report to failsafe-reports... and it we change the directory for the unit tests to e.g. test-reports that could have a regression imact. * Use case 2: Separate Reporting (as separate plugins, they generate reports in separate directories as before) * Use case 3: Separate default binding... consider the case where pluginManagement specifies executions, with separate plugins I can safely define /project/build/plugins/plugin/m-surefire-p and not drag in the default execution of failsafe:integration-test and failsafe-verify So my proposal is as follows: 1. Move failsafe-maven-plugin to https://svn.apache.org/repos/asf/maven/surefire/trunk/maven-failsafe-plugin 2. Refactor maven-surefire-plugin taking the code that is common with failsafe into common module 3. Refactor maven-failsafe-plugin to use the common module. In pseudo code SurefirePlugin would be reduced to execute() { common.runTests(); } Failsafe's integration-test mojo would become execute() { try { common.runTests(); } catch (Throwable t) { // ignore } } 4. Refactor maven-surefire-reporting-plugin to move the xml results parser into the common module 5. Refactor Failsafe's verify mojo to use the xml results parse from the common module. OK, so that's a tad long, but what do people think? Any objections? -Stephen Lazy consensus, 72hrs, i.e. you have until 18:00GMT on 7th Jan 2010 to -1 this (after which you'll have to -1 the commit if you feel strongly against the direction I'm suggesting) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org