Le 2025-04-15 à 14 h 13, Romain Manni-Bucau a écrit :
Assuming you use javac or a standard compiler as known today, this got
proven fragile multiple times even before jpms
When new parameters are added to javac, developers can use
<compilerArgs> as a tedious workaround until the compiler plugin is updated.
But even assuming that, if it is 100% specific to compiler plugin -
for me it can't but i'll not fight much on that since i'll not push
jpms too - then it is trivial to solve -> compiler plugin config and
be it, no need to do anything new in maven.
It is not 100% specific to the compiler plugin. Surefire needs this
information. Javadoc needs this information if generating documentation
for tests.
I fully understand your point but where we disagree is that you
priviledge java over maven whereas maven already superseeds java by design
The `module-info-patch` file is located in `src/test/JAVA` and it
handled by the JAVA compiler plugin. Everything is isolated in Java
space. Nothing force Maven core to be more Java oriented than it is today.
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.
Not really, your solution will end up being the same
No! This is proven by a working compiler plugin, available now, which
does not have the above-cited inconvenient!
didn't mention is that I assume we can use properties for module
references but this is something common for dependencies for ex. With
your patch option you need to invent a new interpolation system and so
on whereas it is built-in with the pom.
No. If someone really wants to use interpolation there, this is already
allowed by the new <source> elements. Not yet implemented in the
compiler plugin, but this feature is in the <source> design and is
independent of the `module-info-patch` proposal.
The projects with JPMS I worked on needed:
- to remove some encapsulation (open depending how you do it)
- drop some SPI (worked around with custom classloaders but it was ugly)
from module-info
- be able to implement a not exported module API for mock purposes
- be able to call an internal API ("partialStart" spirit)
And this is all supported by `module-info-patch`, except dropping SPI
for which there is no Java option to my knowledge.
(about generating module-info from POM):
Just as a matter of fact several plugins we already discussed about do
it. Indeed, some meta are added in the plugin to complete it but it is
a fact this is solved for projects since years.
As pointed out, they need metadata. The POM alone is not sufficient.
Module-info is source code, and it is reasonable to make easy for
developers to control their source code. It does not prevent those who
want to rely on automatically generated source code to continue to do so.
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.
Ok so a no which means yes ;). This is the current practise in
src/test/java.
The developer patches his own module, not the module of someone else.
So test module can't be an applicative test module so you break maven
src/test layout (=you enforce to extract these modules now)?
I do not understand what you mean. No layout is broken, developers can
do the exact same thing as today. The code in `src/test` can patch the
main code (whitebox testing: use `module-info-patch`) or be a different
module (blackbox testing: use `module-info` with a different module
name), at developer's choice.
Once again I fail to see why we should use <dependencies> but not
<jvmOptions> in a plugin or reusable if you want to limit duplication
since it is the way maven is built.
I have nothing against <jvmOptions>, it can be useful sometime. But I
don't think that is is a good fit for JPMS, for the reasons explained
above about <optionsSet>.
Ultimately if you want a built system dedicated to jpms which is very
neat and limits the duplication you should go with a file aggregating
module-info+deps+options then generate all the files with duplication
instead.
I do not understand. Aggregate what? Generate which files?
But this is not how maven works so, once again, it looks like you are
merging maven with yet another build system but the cost to make maven
inconsistent is quite high IMHO.
I think that you see more disruption than the reality:
* Make Maven more Java oriented (no, everything is confined to Java
space: plugin or directory).
* Break test layout (no, it breaks nothing).
* May require interpolations outside the POM (this is already
supported at least in principle, and is independent of this proposal).
* Not generic enough (a working plugin exists, show me a case that it
can't handle).
o Other than "Removing SPI" since there is no way to do that with
standard Java options as far as I know.
Martin
