Bug 38799

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 TasksAssignee: Ant Notifications List <notifications>
Status: RESOLVED FIXED    
Severity: major CC: ant, dk, johnny_hujol, martin.moorhead, mpetras, notifications, pete.cant
Priority: P2    
Version: 1.3   
Target Milestone: 1.7.0   
Hardware: All   
OS: All   
Bug Depends on:    
Bug Blocks: 6606    
Attachments: Working patch
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)