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.
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
Martin
