Bug 38799

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.