I hesitated on first expressing this opinion, but now that there's been some push back, I'll share my initial reaction. I like the plan Stephen set forth, but it may be more appropriate for a 3.0 release of surefire. Although the majority (if not all) of the plugin's behavior is unaffected, the refactoring seems like a new architecture for the plugin.
Paul On Mon, Jan 4, 2010 at 4:45 PM, Dennis Lundberg <denn...@apache.org> wrote: > Just so I understand, when you say the ITs "won't work for release", do > you mean > > 1. They will fail the release process > > or > > 2. The current IT coverage is bad > > Stephen Connolly wrote: >> sorry that may have come off a tad rude. >> >> technically I could rewrite the tests without adding the failsafe stuff, >> but that would look hacky and maven should show best practice not hacky >> >> if you want to release 2.5 before Friday, fine... otherwise I'll do it >> my way >> >> Sent from my [rhymes with tryPod] ;-) >> >> On 4 Jan 2010, at 22:21, Stephen Connolly >> <stephen.alan.conno...@gmail.com> wrote: >> >>> no can do. I need to fix the integration tests... they won't work for >>> release as written... to rewrite them I need failsafe >>> >>> Sent from my [rhymes with tryPod] ;-) >>> >>> On 4 Jan 2010, at 22:13, Dennis Lundberg <denn...@apache.org> wrote: >>> >>>> I'm not familiar enough to with the code bases to judge your proposal. >>>> >>>> What I'd like though is a new step, before the ones you listed, and that >>>> is to release Surefire 2.5 with whatever is in trunk *first*. >>>> >>>> Stephen Connolly wrote: >>>>> 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 >>>>> >>>>> >>>> >>>> >>>> -- >>>> Dennis Lundberg >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > > > -- > Dennis Lundberg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
