I have looked through all our current integration tests regarding failing of build with failsafe, and they all seem to be ok.
You have probably uncovered some unknown problem, and I request that you do the following: svn co https://svn.apache.org/repos/asf/maven/surefire/trunk/surefire-integration-tests/src/test/resources/failsafe-buildfail/ cd failsafe-buildfail mvn -Dsurefire.version=2.12 verify Form that point on I'd be really happy if you could try to modify this project to reproduce the failure, and in that case please submit the modified project attached to a jira. I also just updated the developer guides on how to attach a debugger to the fork, which may be just as simple: http://svn.apache.org/viewvc/maven/surefire/trunk/maven-surefire-plugin/src/site/apt/developing.apt.vm?view=markup Kristian 2012/2/7 Christian Schlichtherle <[email protected]>: > Hi, > > I have now run the integration test suite with plugin version 2.10 and it > always fails. So the results are: > > V2.10: Always fails => correct behavior. > V2.11: Always fails => correct behavior. > V2.12: Always passes => wrong behavior. > > The configuration is the same as before. > > Enclosed is a unified diff of the output from the following command line: > > mvn install -Pintegration-test --debug > > between plugin version 2.11 and 2.12. I could find nothing unexpected in it. > > Regards, > Christian > >> -----Ursprüngliche Nachricht----- >> Von: [email protected] [mailto:[email protected]] >> Im Auftrag von Kristian Rosenvold >> Gesendet: Dienstag, 7. Februar 2012 18:30 >> An: Maven Users List; [email protected] >> Betreff: Re: maven-failsafe-plugin incorrect reports when running >> parallel tests >> >> The thing is, you might be hitting two different problems, which is >> where I'd really like for you to test 2.10. 2.11 had a *known* problem >> with certain classloading combinations, which could cause all tests to >> fail (basically all or nothing, but it would only be hitting users with >> specific libs/deps). >> >> Now this was fixed in 2.12, but SUREFIRE-803 (2.12) does some changes >> to the failure detection algorithm in failsafe, which may be the cause >> of some other problem. We have decent test coverage of these things but >> there's always the chance of some uncovered corner-case. >> >> AFIK 2.10 could be used to benchmark the behaviour of your current >> tests. >> >> >> Kristian >> >> 2012/2/7 Christian Schlichtherle <[email protected]>: >> > Hi Kristian, >> > >> > I've investigated the subject a little more. For both plugin >> versions, >> > I use the same configuration (confirmed by both help:effective-pom >> xor >> > the --debug >> > option): >> > >> > forkMode=once >> > parallel=both >> > useSystemClassLoader=true >> > >> > I also wrote a little test class with two test methods which both >> > simply log the System.identityHashCode() for the test class and its >> > class loader. With both plugin versions, both test method executions >> > report the same class and classloader instance. >> > >> > Yet, with version 2.11 my integration test suite always fails and >> with >> > version 2.12 it always passes. >> > >> > Now what concerns me is that I wouldn't have noticed that there are >> > issues in my code under test if I had started to use >> > maven-failsafe-plugin with version 2.12. >> > >> > My integration test suite is large and long running, so I can be >> > fairly sure it always fails as long as the multithreading issue(s) >> > exist(s) in my code under test. I also know that the issue(s) in my >> > code under test are not classic racing conditions for objects on the >> > heap, but a failure to properly deal with some IOExceptions when >> > concurrently accessing shared file system resources. >> > >> > Regards, >> > Christian >> > >> > >> > >> > --------------------------------------------------------------------- >> > 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] > > > > --------------------------------------------------------------------- > 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]
