ma., 24.01.2011 kl. 00.19 -0800, skrev fmeili: > Do you have any other idea how I may isolate the problem? > TestNG dependencies can also cause the same behaviour as I described in my original mail (wrt junit3).
If that fails, there is no other way than to do as I said: >Surefire stores the fork-configuration for the test run in the >target/surefire folder, and if you "grep" for the correct files >you should also be able to compare the values used for a >successful/failing run. This would be really valuable. >(/me kicks myself in the leg for not making those property files >alphabetical for the 100th time. Create an issue if you feel the same ;) If you manage to isolate two different files that give different results (for the same test run), I would recommend you create a SUREFIRE issue and attach the two files. If you're using forkMode=once it should be fairly simple, it might be a little more work for forkMode=always ;) It should be as simple as tucking away the properties file for a build that works, run until it fails and find the (nev version) of the same property file. > b) > Very interesting, If I don't specify the 4.7 provider explicitly, this > problem has gone When you specify the 4.7 provider as a dependency, that overrides any automatic detection. As long as you activate through setting the "parallel" attribute (instead of using the new forced provider mode in 2.7), you will be using the built-in surefire provider detection. While I suspect this will give you a different provider (and might seem to work), it may also have the unintended side effect of not running junit4 tests :( Kristian --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
