Le mar. 15 avr. 2025 à 11:14, Martin Desruisseaux <
[email protected]> a écrit :
> 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.
>
It is not different than using a patch file.
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 🤔
>
> 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.
>
> modifying the POM for JPMS-specific configuration would be unusual in
Maven.
Agree, but 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>
for ex
this still embraces java (not jpms) but make it fully functional for jpms
as well.
the way I'm seeing it is a superset of feature of jpms but it looks also
more consistent with maven from my window.
> 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.
>
The disavantages are:
- it is a file format which doesn't exist nor is supported by any tool
- it will need a plus/minus mechanism ("diff") to be fully functional for
advanced cases
- 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)
- it is ultra specific to an use case I think it still not mainstream at
all so shouldn't be very specific in the solution to keep the maintenance
accross plugin clear and easy for everyone
>
> 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.
>
Guess I answered in previous points.
Just a side node:
> Would it looks familiar to JPMS users?
Why does it need? classpath definition doesn't look familiar at all to java
users and this is what we want too so not a big deal IMHO.
>
>
> > 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`.
>
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? -
it is common to have beans for the IoC and test code in test modules?
So ultimately the patch file will just configure another file.
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? 🤔
I can ack that if you do not use maven it is smoother to start using maven
but this is probably the opposite of what we want, we already change a lot
in maven 4 for users and not sure this goes in the right direction long
term for the project.
Long story short I think we can do the same logic than for dependencies for
jvm options and let plugin consume "id" which enables to grab a bunch of
customizations.
If you really want to stick with a random file why not doing as gradle
extensions and publishing a maven extension which reads your patch file? (
see
https://github.com/java9-modularity/gradle-modules-plugin/blob/34139d32dcbc066e8c50d24165e7165845eccab6/README.md?plain=1#L386
for the ref ).
>
> Martin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
