Le lun. 14 avr. 2025 à 18:57, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :
> Le 2025-04-14 à 17 h 36, Romain Manni-Bucau a écrit :
>
> > white/black box tests (or whatever name you use today) are a good example
> > which show you need at least two files exactly as today ("without jpms")
> > you play with surefire execution.
>
> The proposed `module-info-patch` is for whitebox testing only. Blackbox
> testing do not need `module-info-patch`, since they use the module as an
> ordinary application.
>
This is not always true, the common case is to inject a mock of an external
service to test an algorithm or alike.
And even assuming there are other ways - this is true - you have all the
categories in between (grey or whatever name you want).
>
>
> > side note: this is not only about surefire but any plugin which can need
> a
> > tuning of the module-info in the actual dependencies/projects.
>
> The `--patch-module` and related options are for *modifying* the
> definition of a module. We are not supposed to do that, except in
> exceptional circumstances such as whitebox testing or for patching a bug
> in the module. When developers want to test a module under different
> environments, they will usually do that by putting different modules on
> the module-path (including modules created specifically for testing
> purposes with different module-info), without altering the existing
> module-info. If nevertheless there is really a need for that, we can see
> how to do that when we have a use case. It does not necessarily
> invalidate the `module-info-patch` proposal, which is for whitebox testing.
>
>
> > I'm not against a specific file if everything jpms related is in this
> > file...which also means the dependencies.
> > What I really do not like is to split the same area of configuration in
> > multiple files.
>
> There is already a strong overlap between the dependencies declared in
> the `pom.xml` file and the `module-info.java` file. The proposed
> `module-info-patch` tries to stay as close as possible to what already
> exists. There is close matches between module-info and module-info-patch:
>
> module-info -> module-info-patch
> ----------- -----------------
> requires -> add-reads
> exports -> add-exports
> opens -> add-opens
>
I get the intent but it creates inconsistencies in maven configuration and
goes against all the hard work you already did which is something I do not
get and ultimately I'd like all the JPMS to stay in the same location, hack
or not.
I'm fine with both options: put it all in the pom or put it all in
jpms-whatever.hack, but it include all options and dependencies
"scope/target/type/option".
Since I think having sets of command line options can make sense more
generally than the JPMS niche usage, I would promote it for everybody and
make it consummable for all plugins as a preference but isolating all JPMS
work in a dedicated file works too if that's what you prefer.
Something in between looks half baked to me and current option to use
plugins to do the patching in the module lifecycle is exactly overlapping
and sufficient IMHO even if not org.apache.maven.plugins based.
>
> Martin
>
>
