|
I'm afraid we can't move to JUnit 4.5+ in the Spring 2.5.x branch. However, in the upcoming Spring 3.0 branch, we'll build on JUnit 4.5. Juergen Please make sure you use junit:junit-dep:4.5 rather than junit:junit:4.5. It properly defines a dependency on org.hamcrest:hamcrest-core:1.1 whereas junit:junit:4.5 bundles the classes inside of itself. This causes problems when using org.jmock:jmock-junit4:2.5.1 because hamcrest classes then appear twice on classpath. What prevents the fix in 2.5? Well, the 2.5 branch entered strict maintenance mode last week. While we are in principle still able to support new versions of third-party dependencies, we can't raise the minimum level unless the previously supported version was pre-release software. Unfortunately it seems that supporting JUnit 4.5 here means requiring JUnit 4.5+; we can't do that before Spring 3.0 since all sorts of present build and development environments have JUnit 4.4 baked into them. It's unpleasant but not our fault - there was no better way of doing the test context framework against the hard-to-extend JUnit 4.4. Juergen Reopening to complete the migration from JUnit 4.4 to JUnit 4.5 including custom Statements and extension of BlockJUnit4ClassRunner. JUnit 4.6 is already available. The Spring TestContext Framework is now based on JUnit 4.5. Hi Leo, The patch you're referring to was submitted by Henrik Kaipe in September 2008. Thus if you would like to use his work against Spring 2.5.6, you would need to contact him directly or figure out how to upgrade the patch on your own. Please note, however, that I upgraded the Spring code base in trunk to work with JUnit 4.5. This code applies to Spring 3.0.0.M3 as well as the upcoming 3.0.0.RC1 and 3.0.0.GA releases. Thus, if you can start using Spring 3.0, you won't need a patch. Regards, Sam Hi Sam, Thanks for your reply! Unfortunately I can't go to 3.0 anytime soon. My company is pretty strict about software versions and probably won't be "accepting" 3.0 for some time. I'm in a bit of a tough spot as we're using the latest version of Concordion to execute spring injected tests. This latest version of Concordion requires the 4.5 version of junit to function, which obviously conflicts with what Spring 2.5.6 needs. Given this combination is only being used in isolated testing, patching the 2.5.6 version shouldn't be blocked by "the man". I'll try mucking about with the patch. First I need to get the spring sources to compile. build.bat alljars keeps throwing compilation errors (before applying the patch). Anyways, thanks! Leo, Disclaimer: I've not tried this, and it's not "supported", but... You could likely take the 2.5.6 build, simply copy the 3.0.0.M3 code for the org.springframework.test package over it, and then create your own "reverse engineered" patch. Obviously the work I did in the 3.0 branch built off the 2.5.6 branch. So theoretically it should work. That might prove easier than reverse engineering the patch in this JIRA, and it would be more likely to be forward compatible. Good luck in any case! Sam FYI: For those of you still following this issue, the Spring TestContext Framework is now based on JUnit 4.6.0 as of Spring 3.0.0.RC1. See also: Regards, Sam Hi froc, The Spring TestContext Framework in Spring 2.5.6 only works with JUnit 4.4. There unfortunately will not be a patch to support JUnit 4.5 plus with the Spring 2.5.x branch. On the other hand, Spring 3.0 supports JUnit 4.5, 4.6, and 4.7. That may not be the answer you hoped for, but I hope it clarifies the situation for you. Regards, Sam
Whilst I understand the main argument made here, this is getting a bit unpleasant now with the release of JUnit 4.7, as basically (given that Spring 3.0 GA has not been made available yet and Spring 2.5.X will not be changed anymore) we are not in a position anymore to simplify (and hence increase the test code quality of ) our test cases based upon the recent additions to JUnit 4.7 (such as new ''expected'' parameter on {@Test}, etc.). Werner, Spring 3.0 GA is now scheduled for Monday Dec 14 (i.e. in four days); it is literally around the corner. Also, using last week's 3.0 RC3 for the time being is going to ensure a smooth upgrade path to GA, since we are sorting out very specific bugs only at this point. So 3.0 RC3 is a fine release and very recommendable for development purposes already; I just wouldn't go to production with it yet. With respect to using a brand-new JUnit version with older versions of Spring: Fundamentally, there is no reason to keep holding on to Spring 2.5 when upgrading other parts of your stack. Take JUnit, or Tiles, or JRuby - all of which we support in new versions now in Spring 3.0 that did not work with Spring 2.5. All of those libs require Java 5 anyway, so the Java 5+ requirement in Spring 3 shouldn't be a showstopper for anyone here. We are trying to be forward compatible as far possible but well, if JUnit breaks its runner contract from 4.4 to 4.5 and Spring 2.5 only had JUnit 4.4 to work against at the time, there is not much we can do other than catch up with the latest JUnit release in the latest generation of Spring. In particular sine Spring 2.5 has to remain compatible with JUnit 4.4 for support reasons: i.e . for people who stick with their original stack from back in 2007... In summary, please give Spring 3.0 RC3 a try and let us know whether its JUnit 4.7 support works for your purposes Juergen Thanks, Jürgen, for letting me know about the immediate release date for 3.0. This should ease our pain substantially. And we will definitely give things a try re: JUnit 4.7, etc. 3.0 GA isn't released yet, is it? Dennis, 3.0 GA is tentatively scheduled to be released... today! How about creating a separate artifact for the 2.5 branch with Junit 4.5+ support? Probably you won't take that route anymore, but still, it's an idea, at least for the future. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
On top of the patch - make sure you also replace the old spring/lib/junit/junit-4.4.jar with the new junit-4.5.jar, which can be downloaded here:
http://sourceforge.net/project/showfiles.php?group_id=15278&package_id=12472
The patch offers a solution where SpringJUnit4ClassRunner extends the new JUnit4.5 class "BlockJUnit4Runner", which offers much better possibilities for extension and reuse than the old class JUnit4ClassRunner, which have been deprecated.
This also means that backward-compability to JUnit-4.4 is broken but I think it is worth it. Its default class-runner JUnit4ClassRunner was not really supposed to be extended the way SpringJUnit4ClassRunner did it. (Not that there was any good alternative but still ...) Also, by switching to JUnit-4.5 the classes SpringTestMethod and SpringMethodRoadie can be removed.