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
