modulepath and classpath mixture

[Alan Bateman]

On 22/02/2016 20:44, Robert Scholte wrote:
> Hi,
>
> first of all I'd like to say that I'm very pleased with the new -mp 
> options, these matches better with the way Apache Maven would like to 
> work with jars and class-folders.
>
> Here's my use case: I noticed that if I add a module-info to 
> src/main/java and put all compile-scoped dependencies to the module 
> path, all compiles fines.
> I assume that developers are less interested in adding a 
> module-info.java file to src/test/java, so that's what I'm doing right 
> now too.
> Now it seems that I *must* add compile + test scoped to the 
> *classpath* to be able to compile the test classes.
> My first approach was to leave the compile-scoped dependencies on the 
> modulepath and all test-scoped dependencies on the classpath, so the 
> modules keeps their inner related structure, but it seems that the 
> classpath classes cannot access the modulepath classes.
>
> I'm looking for the confirmation that putting all dependencies on the 
> classpath is indeed the right approach in this case.

For the tests then I assume they are in the same packages as the sources 
under src/main/java, is that right?

In that case I think you will want to compile the tests as if they are 
part of the module:

   javac  -Xmodule:m  -d testclasses/m  -mp m.jar  test/java/...

where m is the module name and the module (with sources in 
src/main/java) has already been compiled and then packaged as m.jar. The 
-Xmodule:<module> option tells the compiler that you compiling the test 
classes as if they are part of module m. There is no module-info.java in 
the test tree.

Going further then I expect that JUnit or TestNG is also in the picture, 
I assume the class path. In that case, the command becomes:

   javac  -Xmodule:m  -d testclasses/m  -mp m.jar   \
       -cp junit-4.12.jar  -XaddReads:m=ALL-UNNAMED  \
       test/java/...

where you are compiling test classes as if they are module m and at the 
same time referencing JUnit types on the class path. The 
-XaddReads:m=ALL-UNNAMED augments the module declaration to say that 
module m reads all unnamed modules, just think class path here.


In order to run then you can use -Xpatch to augment the module with the 
test classes:

   java -Xpatch:testclasses  -mp m.jar  -cp junit-4.12.jar 
-XaddReads:m=ALL-UNNAMED   ...

It is as if the test classes are in m.jar. The alternative is of course 
to add the test classes to the packaged module but you would still need 
the -XaddReads because module m does not (and can not) declare that it 
depends on types on the class path.


While on the topic then I should mention that we have a proposal coming 
to support patches as JAR files as I'm sure you will get to the point 
soon where the test classes are in a JAR file.

Hopefully the above is useful. I completely agree with Jon that we need 
to put down detailed notes and examples. In the case of testing then we 
have tried out the popular test frameworks on the class path (as above) 
and also as modules. In the case of JUnit then we have been successful 
with it on a the module path as an automatic module. Definitely 
something to write up.

-Alan