On 08/03/2016 19:13, Robert Scholte wrote:
This is how I thought that -Xpatch would work in short: the
module-info in src/main/java and src/test/java have both the same
modulename. The module-info in src/test/java specifies the extra
required modules (like junit). With -Xpatch the test-classes have
access to the non-exported main-classes too.
If the sources in src/test/java are a completely separate module then
they will have their own module declaration.
If the tests are instead intended to augment the module, say where the
tests are in the same package as the code under test, they will not have
their own module declaration. This means no module-info.java in
src/test/java. As things currently stand then javac -Xmodule:$MODULE
will ignore the module-info.java when you compile the sources in
src/test/java. At run-time then you'll get a warning if there is a
module-info.class found when patching a module.
So I think you will need to get the module name when compiling the
tests. You should not need the module name when compiling the code in
src/main/java of course. The complication for the tests as they are
being compiled "as if" they are part of the module.
As the tests classes in the same module as the main classes then it
means the tests have access to all public types in the modules (no
exports are needed). Furthermore, they are in the same package as the
main classes then they have access to private package types/methods too.
The final part will be running the tests as the injected test classes
will have dependences on JUnit or TestNG tests. They module declaration
doesn't declare that it requires those and this is why we need to
augment it at run-time with -XaddReads so that it reads the JUnit
module. There are choices here as to whether JUnit is deployed on the
class path or module path, it can work as either.
-Alan
