modulepath and classpath mixture

[Robert Scholte]

On Mon, 07 Mar 2016 14:53:28 +0100, Sander Mak <sander.mak at luminis.eu>  
wrote:

>
>> I don't think I understand the issue here. Using -Xpatch doesn't change  
>> the module declaration or export. It can be used to override or augment  
>> the module content, it just can't override the module declaration. It  
>> can be used in conjunction with -XaddReads and -XaddExports to read  
>> additional modules or export additional packages. For example, if a  
>> patch adds types to a new package then you could export that package  
>> with -XaddExports. If the patch injects tests into an existing package  
>> then those tests might have new dependences and requires compiling or  
>> running with -XaddReads:$MODULE=junit for example.
>
> I was playing around with exactly this yesterday, and this is what I  
> ended up with:
>
> javac -Xmodule:javamodularity.easytext.algorithm.naivesyllablecounter \
>       -XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit  
> \
>       -mp mods:lib-test \
>       -d  
> mods-test/javamodularity.easytext.algorithm.naivesyllablecounter $(find  
> src-test -name '*.java')
>
> java -Xpatch:mods-test \
>      -XaddReads:javamodularity.easytext.algorithm.naivesyllablecounter=org.junit  
> \
>      -XaddExports:javamodularity.easytext.algorithm.naivesyllablecounter/javamodularity.easytext.algorithm.naivesyllablecounter=org.junit  
> \
>      -mp mods:lib-test \
>      -addmods  
> javamodularity.easytext.algorithm.naivesyllablecounter,hamcrestcore \
>      -m org.junit/org.junit.runner.JUnitCore  
> javamodularity.easytext.algorithm.naivesyllablecounter.NaiveSyllableCounterTest
>
> Which patches my application module to contain a unit test, and then  
> exposes my application module to junit at runtime (which is used as  
> automatic module here). This works as expected.
>
>
> -- Sander

When translating this to Maven it assumes that Maven is aware of the  
module name of the project is it building.
Up until now that's not true. Developers specify the moduleName in the  
module-info.java and it doesn't make sense to ask them to add the same  
modulename to the pom (it that was possible) or the maven-compiler-plugin  
configuration. Instead Maven could use some new java9 APIs to discover the  
moduleName, but that would imply that from now on maven-compiler-plugin  
requires Java9 runtime. I don't think that's the way we want to go right  
now. Several Maven plugins have their own kind of multi-release pattern  
where some codeblocks depend on a specific Maven version, but we really  
want to avoid this.
I hope we can find a way where Maven can simply refer to the  
classes-directory or the jar for some java/javac arguments where one would  
now need to be aware of its module name.
 From Mavens point of view the output directories are facts, dependencies  
 from the pom.xml too, as is the packaged artifact name & location, the  
content of java files are a mystery and not of any interest (at least in a  
classpath world ;) ).

thanks,
Robert