Le 2025-04-15 à 08 h 01, Romain Manni-Bucau a écrit :
Depends if exported or not, but if it is an interface or abstract class just to enable the module itself pluggability and testability you still need to do some homework.
If the homework are reflection, there is no --add-opens or other options needed for public methods in public and exported classes or interfaces.
I'm not sure how to read that but putting your file in the pom is not crazy for a build system based on a pom.xml file, is it?
The issue is that there is no place in the current POM for a configuration that applies to all Java-related plugins. If we add a new mechanism for allowing other plugins to access the configuration of the Java compiler plugin, it would make plugin evolution more risky since a change in the parameters could potentially impact an unknown number of plugins. A little bit like making all the private fields of a class public.
Alternatively, we could modify the POM in a way similar to the addition of the <source> elements. But the recently added <source> is still generic: even its <module> sub-element can map to some notion of module in many languages. By contrast, modifying the POM for JPMS-specific configuration would be unusual in Maven. I'm not aware of any other element in the POM which is so specific to one particular feature of one particular language.
There is an overlap between POM and module-info, so we are already in a situation where developers must know what is in the POM and what is in module-info. The advantage of the module-info-patch approach is that it is a mirror of module-info with a straightforward rule: everything that a developer would like to change in module-info for testing purposes is declared in module-info-patch. Everything that is not in module-info is not in module-info-patch neither. It is not obvious that moving the parameters to the POM would not be more confusing.
Proposing to put all parameters in the POM is a bit vague. Which syntax (e.g., do we need to repeat the module name)? Which way to make the information accessible to the Surefire plugin? Which way to separate module configuration from other options? Would it looks familiar to JPMS users? This is why a snippet showing alternative proposals would be useful.
What would you say if I do a PR, merge in rc4 and say: ok, now you put your dependencies in src/main/dependencies.txt, your plugins in src/main/plugins.d/myplugin.txt and so on?
The module-info-patch proposal does not change in current Maven habits except the replacement of `src/test/java/module-info.java` by `module-info-patch.*` in same directory. Quite the contrarily, this is a smoother transition from current habit than asking to move the `module-info.java` content to `pom.xml`.
Martin --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
