On Tue, 23 Feb 2016 13:59:13 +0100, Alan Bateman <alan.bate...@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/
