|Summary:||<junit> task should work so long as junit.jar present in <classpath> even if not among Ant libs|
|Product:||Ant||Reporter:||Jesse Glick <jglick>|
|Component:||Optional Tasks||Assignee:||Ant Notifications List <notifications>|
|Severity:||major||CC:||ant, dk, johnny_hujol, martin.moorhead, mpetras, notifications, pete.cant|
|Bug Depends on:|
Manual test case
Description Jesse Glick 2006-02-27 20:38:21 UTC
A general problem with <junit> has come up repeatedly, as described well here: http://issues.apache.org/bugzilla/show_bug.cgi?id=6606#c22 I am splitting this off into a separate issue as #6606 seems to have a lot of other meanings and I want to be concrete. The problem is that if you have ant-junit.jar in your Ant lib dir (the default situation if you have installed Ant) but you do not have junit.jar in your Ant lib dir or $CLASSPATH or -lib etc. (again, the default situation), the <junit> task does not work. This is true even if you have explicitly added junit.jar to the <classpath> for the task (<junit>, not <taskdef> which cannot work on a task already in your lib dir). That doesn't make much sense and it imposes an artificial requirement on people to adjust their Ant startup classpath. That means that you cannot write a completely self-contained Ant project that runs unit tests. This patch fixes that. While I cannot find Tobias' original proposed patch, I think this accomplishes as much, and furthermore works in unforked mode. I'm not really sure how to unit-test this since the Ant unit tests assume a lot of environment is set up, and specifically they will assume that junit.jar is on the test classpath. So I'm relying on manual testing of various situations: 1. Forked mode vs. unforked mode. 2. junit.jar on system CP vs. not. 3. junit.jar in test <classpath> vs. not. Desired behavior is that tests run fine if either #2 or #3 or both. (If neither, a simple error is reported.) Current behavior is that tests do not run if #3 but not #2. Compatibility: unless I made a mistake, should be fully compatible. Any build scripts which worked before should continue to work the same way: junit.jar must have been on system CP, and <junit> will behave as it did previously. The change should only affect situations where junit.jar was not on system CP, which could not have worked before. The patch is a bit icky since it needs to use some reflection to isolate the junit.jar-dependent portions of the task. The result is mostly transparent and should not harm existing code subclassing some of the classes in this package, I think, but it does add some to the complexity of this task. Perhaps someone knowledgeable could simplify it but I was afraid of breaking foreign code referring to these classes, which are all public. Note that since both "halves" of the task remain in the same source root, the compiler does not enforce the separation - a full fix would move the junit.jar-dependent classes to a separate source root, to ensure that they are not statically accessible from the main source root, and ideally even to put them in a separate JAR file at runtime.
Comment 1 Jesse Glick 2006-02-27 20:40:58 UTC
Created attachment 17802 [details] Working patch Does not include docs, WHATSNEW, @since, etc. Needs further testing, possibly refinement.
Comment 2 Jesse Glick 2006-02-27 20:43:07 UTC
*** Bug 1118 has been marked as a duplicate of this bug. ***
Comment 3 Jesse Glick 2006-02-27 20:43:44 UTC
*** Bug 7081 has been marked as a duplicate of this bug. ***
Comment 4 Jesse Glick 2006-02-27 20:44:22 UTC
*** Bug 14931 has been marked as a duplicate of this bug. ***
Comment 5 Jesse Glick 2006-02-27 20:44:28 UTC
*** Bug 33440 has been marked as a duplicate of this bug. ***
Comment 6 Jesse Glick 2006-02-27 20:45:00 UTC
*** Bug 36862 has been marked as a duplicate of this bug. ***
Comment 7 Jesse Glick 2006-02-27 23:00:05 UTC
Created attachment 17805 [details] Manual test case Tries various combinations of options: 1. Ant 1.6.5 vs. patched Ant 1.7. 2. JUnit 3 vs. 4. 3. junit.jar in $CLASSPATH or not. 4. junit.jar in <classpath> or not. 5. fork="true" vs. fork="false". 6. Custom <formatter> or not. Some paths hardcoded at top of file.
Comment 8 Jesse Glick 2006-02-27 23:28:54 UTC
revision 381467 Let's see if any regressions are found. Also tested successfully inside NetBeans IDE 5.0, to make sure the same fix works even inside a container with its own class loaders etc. Had to install a module containing a JAR entry ---%<---META-INF/services/org.apache.tools.ant.module.spi.AutomaticExtraClasspathProvider #-org.netbeans.modules.junit.JUnitClasspathProvider ---%<--- which suppresses the IDE's normal inclusion of junit.jar into the Ant classpath. Then when running without -J-Xverify:none (which sometimes makes even 1.6.5 work, if it happens not to try to load any junit.** classes), Ant 1.6.5 inside the IDE fails on a plain Java project with unit tests but patched 1.7 succeeds, incl. with JUnit 4.
Comment 9 Tobias K. Tobiasen 2006-04-27 20:28:22 UTC
Excellent. This has been a big annoyance for a lot of people. > Note that since both "halves" of the task remain in > the same source root, the compiler does not enforce the > separation - a full fix would move the junit.jar-dependent > classes to a separate source root You could use jdepend to enforce the separation. (http://clarkware.com/software/JDepend.html)