Le 2025-04-15 à 11 h 53, Romain Manni-Bucau a écrit :
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.
It is not different than using a patch file.
It is different in that `module-info-patch` is parsed by the compiler
plugin only, and "compiled" in a set of JVM parameters that Surefire can
use. Surefire does not need to know anything about `module-info-patch`.
Also there is no place for now in the pom as there was no place to set
a jpms module, we did half of the work there, not sure I understand
why you are reluctant to finish the work and try to use a quick a
dirty solution there 🤔
Because I disagree that it covers only half of the work and is a dirty
solution. I do not see a more elegant solution at this time regarding
integration with the existing practice of writing a `module-info.java` file.
there it is more generic options, not JPMS specific, could even be a
-Xmx (likely a wrong example but you get the idea hopefully).
<optionSets> <!-- or jvmOptionSets maybe
<optionSet>
<id>compilation-base</id>
<values>
<value>...</value>
</values>
</optionSet>
</optionSets>
with such a config the plugin can consume
<jvmOptionSetIds><jvmOptionSetId>compilation-base</jvmOptionSetId><jvmOptionSetId>compilation-j24</jvmOptionSetId></jvmOptionSetIds>
But this approach is more verbose and tedious to write, both because XML
and because it forces users to repeat the module names in --add-reads,
--add-exports and --add-opens parameters, something that the
`module-info-patch` approach handles automatically. It forces all
plugins to support the `add-reads TEST-MODULE-PATH` special value, while
the `module-info-patch` approach resolves that for them. Furthermore, I
believe that there is value in treating the module configuration
parameters separately from other parameters. They are special in that
they modify a source code written by the developer: the content of
`module-info`, and putting them in a `module-info-patch` file makes that
fact clear. It does not mean that the <optionSet> proposal wouldn't be
useful for other use cases, but not necessarily for module configuration.
The disavantages are:
- it is a file format which doesn't exist nor is supported by any tool
As is the addition of <optionSets> element in POM, with the additional
difficulty that tools would have to separate this element from the other
Maven stuff in a POM, and then separate the module configuration options
from other options mixed in that element.
- it will need a plus/minus mechanism ("diff") to be fully functional for
advanced cases
I do not see which advanced cases you are referring. Can you provide a
concrete example, JPMS parameters included?
- it provides some configuration outside the source of truth (pom -
and you are right there is module-info file already but a lot of
project just generate it from code+pom already)
A module-info cannot be generated properly from the POM, as the latter
has no information about which packages to export, which packages to
opens, which services to declare, which services to implement, and which
dependencies to make transitive ("transitive" here does not have the
same meaning as Maven). The source of truth of `src/main/java` is the
combination of the POM and module-info. The `module-info-patch` approach
is an extension of that fact to `src/test/java`. In my opinion, this is
the most natural extension as it reuses the existing pattern.
Hmm, maybe I'm not thinking to the same use case than you but
ultimately you need both files if test module provides is also an
actual module no?
No. if the tests are provided in their own module, there is no need to
patch those tests. For example, there is no need to patch JUnit for
using JUnit. We only patch the module which is *using* JUnit.
On the habit point I'm also not sure, why is it smoother to not use
the pom for a system where you have only the pom? 🤔
Because we don't have only POM. We have POM + module-info.
* Main code = POM + module-info
* Test code = POM + module-info-patch
* Module-info-patch is mirror of module-info: it contains the stuff
that modify the main module-info, and nothing else.
Can you see the symmetry and how it fits nicely in the existing pattern?
Putting the module configuration parameters in the POM is the dirty
approach.
Martin
