Le 2023-10-29 à 21 h 36, Romain Manni-Bucau a écrit :
Was referencing the options using module names, if you drop the dep or
reference a package not supported by the module we should be able to fail.
I do not want to distract this thread from the core issue (control on
class-path versus module-path), but I believe that above concern can be
avoided. Lets take --add-exports as an example. The syntax of the option
passed to javac is:
--add-exports source/package=target
Where /source/ and /target/ are module names. For example if a project
is a module named "my.project" and that module is using the "org.junit"
module as a dependency, we may want to add the following option:
--add-exports my.project/my.internal.package=org.junit
It is possible to design the Maven POM in such a way that those modules
are inferred from the context. The POM could look like this (simplified):
<artifactId>my-project</artifactId>
<!-- with a module-info declaring "my.project" -->
<dependencies>
<dependency>
<artifactId>junit</artifactId>
<!-- with a module-info declaring "org.junit" -->
<scope>test</scope>
<add-exports>
<packages>
<package>my.internal.package</package>
<!-- Repeat for other packages to export -->
</packages>
</add-exports>
</dependency>
</dependencies>
Above would mean: if the JUnit dependency is added on the module-path
(which happens only during tests), then automatically generate
--add-exports options with:
* The enclosing project ("my.project") as the source module.
* The enclosing dependency ("org.junit") as the target module.
* The specified <package> elements as the packages to exports.
A similar approach can be applied to other options. That way, module
names do not appear anywhere and the inconsistency risk does not exist.
This proposal does not cover all cases, but would provide a safe and
easy way for probably the majority of cases. If a user needs to specify
different modules than the ones inferred from the context (s)he can
still add the --add-exports option manually on the command-line.
Martin
