ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Clarke <>
Subject Re: svn commit: r1460264 - in /ant/core/trunk: WHATSNEW build.xml src/etc/poms/ant-junit/pom.xml src/etc/poms/ant-junit4/ src/etc/poms/pom.xml
Date Wed, 27 Mar 2013 22:48:28 GMT
> +* the optional ant-junit4.jar has been merged into ant-junit.jar
> +  as Ant now requires JUnit4.

Is it really the case that Ant requires JUnit4? The changes I
introduced for @Ignore annotations in Ant 1.9.0 shouldn't impact
backwards compatibility with JUnit3 and I don't believe any other
changes in the 1.9.0 release force users to need the JUnit4 jar whilst
running tests.

JUnit3 is still available for downloading from various sites and users
working against older codebases may still have it bundled in their
workspace so it's not infeasible that someone way want to run tests
using JUnit3 and Ant 1.9.0 or above.

That being said, it should be possible for users to drop the JUnit4
jar in as a direct replacement to the JUnit3 jar in these cases; so we
wouldn't be forcing users wanting to upgrade Ant to perform
particularly high risk tasks. The real question is: was there a
technical reason for making this change or are we just looking to
limit limit the dependency on older libraries?

If the switch to JUnit4 is intentional then the JUnit task could do
with some tidying up to remove Java 1.4 checks, remove the reflection
used to guard against JUnit4 not being on the classpath, and merge the
split of code used to protect JUnit3 backwards compatibility. I
currently have changes pending (for once I get commit access) which
will allow the JUnit task to be 'intelligent' about which classes it
passes to the JUnit core [1] and am happy to perform a bit of tidy
up/refactor of the existing JUnit task code at the same time if we're
guaranteeing JUnit4 is on the classpath when the JUnit task if called.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message