I’d like to take a step back here. It may be that I have completely misunderstood what is going on, but this all seems to have gotten way more complicated than it should.
I am assuming: 1) the project has both module and class path compile dependencies, and possibly has both module and class path test dependencies as well. 2) the artifact type “module” (or something similar) is now recognized as indicating a Jigsaw module (which needs to go on the module path) 3) the classes being built may be put into their own module, but might not be. Then there are really four categories of dependencies. The compile step needs to place its jar dependencies on the class path and its module dependencies on the module path. I presume that is what Robert is already doing. The test-compile step needs to handle all four, including the compiled class in its test class path. Then there is no need to compile either the main or test classes as part of a module. They may use modules, but that is a different matter. No need for the -Xmodule switch at all. The only reference to module is as dependencies. Did I completely miss the point? - Russ > On Feb 23, 2016, at 7:59 AM, 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. > > 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
