Ant JunitTask update to support JDK9 modules

[Ali Ebrahimi]

Hi,

I previously proposed module group concept that its member modules can be
loaded by same classloader.
If one module doesn't define its module goup, that defaulted to module's
name.

module ant.junit{
    group:  ant.junit; //this can be emitted: default values is module name
}

module ant.junit4{
    group:  ant.junit;
...
}

This way we can localize and somehow solve split package problems and
provide support for migrating existing jars in maven repositories that have
splited packages.

On Thu, Apr 28, 2016 at 1:56 AM, 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
>
> Alex
>



-- 

Best Regards,
Ali Ebrahimi