Ant JunitTask update to support JDK9 modules

[Tomas Zezula]

> On 27 Apr 2016, at 23:26, Alex Buckley <alex.buckley at oracle.com> wrote:
> 
> On 4/27/2016 1:41 PM, Jan Lahoda wrote:
>> On 27.4.2016 21:30, Alex Buckley wrote:
>>> Your changes skyrocket in complexity because your Ant setup involves
>>> both ant-junit.jar and ant-junit4.jar. The JUnit task documentation
>>> (https://ant.apache.org/manual/Tasks/junit.html) doesn't suggest this is
>>> necessary or desirable. It's either pointless or dangerous to have both
>>> JARs on the classpath, which is why the module system rejects them as
>> 
>> I think it would be useful if you could elaborate on why using both
>> ant-junit.jar and ant-junit4.jar is pointless or dangerous. What I see
>> in the jars, the org.apache.tools.ant.taskdefs.optional.junit package is
>> perfectly partitioned between the jars (there is no class that would be
>> in both jars). It seems ant-junit4.jar cannot work by itself, without
>> ant-junit.jar. I am not 100% sure what ant-junit4.jar does, but it seems
>> it aids in running single test method in a JUnit 4 way. There appears to
>> be some fallback to JUnit 3 style if the JUnit 4 style is not available,
>> but it is hard to say if that is sufficient. So dropping (the content
>> of) ant-junit4.jar would mean at least careful testing, but more
>> probably a loss of a significant feature.
> 
> Perfect partitioning of a split package is uncommon. The common case is some overlap of types, leading to obscure mix-and-match problems, so the module system rejects a split package unconditionally. Ant's redistribution of JUnit JARs (or perhaps its JUnit's own scheme for v3-to-v4 migration) is architected in a way that's at odds with the module system.
> 
> It might be possible to make a case for relaxing the anti-split-package provision for automatic modules, since they're coming from the classpath world where every artifact is "open" to combination with artifacts elsewhere on the path. But that would reduce reliability, since generally it's a _feature_ that the module system warns:
> 
> java.lang.module.ResolutionException: Modules ant.junit4 and ant.junit export package org.apache.tools.ant.taskdefs.optional.junit
> to module hamcrest.core
It’s exactly as Jan described. The ant-junit.jar and ant-junit4.jar are perfectly partitioned. Neither the ant-junit.jar nor the ant-junit4.jar is a redistribution of junit.
The ant-junit.jar contains an implementation of Ant specific junit runner, the Ant does not use org.junit.runner.JUnitCore runner. The ant-junit4.jar contains just
an adapter of Junit 4 API to JUnit 3.8 API for execution of tests and listening of events.
These two jars were always an Ant implementation detail, there were put on classpath of the tested application automatically by an Ant. No change in this.
The junit library needs to be either on classpath or newly on modulepath. I’ve described both these scenarios in the junit.html of the Ant manual.
I personally prefer to put the test framework on classpath (unnamed module) with -XaddReads:${module.name}=ALL-UNNAMED -XaddExports:${module.name}/my.test=ALL-UNNAMED
especially in case of generic generated build scripts. It’s very easy for an user to add another test framework just by adding it on classpath. There is no need to modify jvm options as the unnamed module
is already covered.
— Tomas
> 
> Alex