Advice + proposals regarding automodule naming

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Robert Scholte" <rfscholte at apache.org>
> À: forax at univ-mlv.fr
> Cc: jpms-spec-experts at openjdk.java.net, "Brian Fox" <brianf at sonatype.com>
> Envoyé: Jeudi 19 Janvier 2017 21:07:51
> Objet: Re: Advice + proposals regarding automodule naming


[...]

>>
>> The real problem is that you can have jars in the classpath and in the
>> module path, and it doesn't mean the same thing.
> Exactly!
> 
>> Build tool do not have to manage automatic modules, you have to manage
>> automatic modules only if you introduce a rule that decide where to put
>> each jar.
> 
> That rule is already there, it is the "require M.N" in the module-info
> file, but it isn't aware if that module automatic or not. This file should
> be the only place where people should care about Jigsaw related
> definitions. 

clever :)

So you start with the current code, check if there is a module-info.java, if so all required modules need to be in the modulepath recursively, everything else is in the classpath.

> At conferences THE returning question is: can you generate
> the module-info for me, because I've already specified my dependencies in
> the pom. So there is already some frustration here, so we most be very
> clear what belongs where and what every responsibility is:
> pom.xml : specify the dependency coordinates you want to use, so Maven can
> download them and can make them available for the maven-plugins
> module-info.java : specify the modules required to compile and/or run;
> these will be checked upfront to confirm everything is there.
> maven-compiler-plugin : build up the correct arguments to call the java
> compiler.

I agree,
you also need to crosscheck that the rules in the pom.xml match the rules in the module-info.java (or the other way around). 

> 
> In the <configuration> of the maven-compiler-plugin it is of course
> possible to define which jars belong on which path, but that would make it
> very hard to use and maintain.

but at the same time you have need a way to be able to see a plain old jar as a modular jar (without being an automatic module) to ease the transition.
Here i think you need the user to say, Maven help me to generate a synthetic module (a synthetic module-info.class that will be injected in the jar of the dependency)
from the information available in the pom of that plain old jar.
It's not clear to me if this is something that should be in the configuration or in the dependency of the pom.

> For example: for test-compile I could have added a parameter called
> "moduleName" and use this value for the -Xmodule: argument. I've decided
> not to do so, because the name is already specified in the module-info.
> For me it was kind of frustrating that one assumed the name of the module
> was a given fact, which implied I had to parse the module-info file. b+148
> killed this strategy for a while, but it is fixed again. If only I could
> have point to target/classes ... ;) Anyway, this is solved once the
> structure of the module-info file is final.

i've decided to not use -Xmodule to run the test but to merge the module-info.java of the test and the module-info.java of the main,
this allows me to be able to specify test only dependencies like junit in the module-info.java of the test.

> 
> To prevent users to add their requirements to the module-info file AND
> specify which jars belong on which path in either the <dependency> or the
> <configuration> of the maven-compiler-plugin, I think we should "simply"
> read the module-info.java*, gather all requirements and find the matching
> jar. And do that recursively.
> 
> * I maintain QDox, a Java source parser, as well.

This is exactly what i'm doing [1] but i use javac instead of writing my own parser :)
(the fact that i can requires the module java.compiler makes the things easy)

> 
>> And also do not forget that deciding to put every jars in the modulepath
>> do not work because of split packages.
>>
> Exactly!
> 

[...]

Rémi

[1] https://github.com/forax/pro/blob/master/src/main/java/com.github.forax.pro.helper/com/github/forax/pro/helper/parser/JavacModuleParser.java