modulepath and classpath mixture

[Robert Scholte]

On Tue, 23 Feb 2016 13:59:13 +0100, Alan Bateman <Alan.Bateman at oracle.com>  
wrote:

>
> 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.

The related lifecycle phases of Maven are: compile, test-compile, test,  
package.
So during test there's no m.jar yet, but target/classes or target/mods/m.  
This shouldn't be an issue, though.

If I understand this correctly I need to know the module name. That is  
information defined in the module-info, meaning I need to read that class  
first. When possible I would like to avoid this. Suppose a developer has  
made a syntax failure, I would hope that such error is thrown by javac,  
not by Maven while doing some pre-compile actions on the source-files to  
construct the correct commandline arguments.

I've already talked with Mark about the usage of -Xpatch, but that's  
required if src/test/java is considered a module too.

And maybe this is the key question: if src/main/java is a module, should  
we handle src/test/java as a module too or leave it as a classpath based  
project?

thanks,
Robert

>
> 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


-- 
Using Opera's mail client: http://www.opera.com/mail/