Le lun. 14 avr. 2025 à 15:03, Martin Desruisseaux <
martin.desruisse...@geomatys.com> a écrit :
> Hello Romain
>
> Le 2025-04-14 à 14 h 28, Romain Manni-Bucau a écrit :
>
> > (…snip…)
> >
> > Doesn't it sound better than a file which looks like a java thing but is
> > not (content), has no editor support (extension), will need to be
> supported
> > by all plugins and still requires its location to be configurable since
> you
> > can need to run surefire with multiple configurations to test different
> > cases (different group sets in my proposal).
>
> My previous email anticipated that point. As said, other plugins do not
> need to know about this file. Only the compiler plugin parses that
> `module-info-patch` file. For the convenience of other plugins, the
> compiler plugin would produce somewhere (maybe in the META-INF directory
> of test classes) a file containing the options ready for use by the Java
> launcher. Other plugins are free to use it, ignore it or amend it.
>
You can move the configuration need to a file location and keep the build
configuration split between the pom.xml and this new file format which
doesn't exist but still the question is valid and I think it goes against
maven without real pro to move in that direction.
>
> There is not much room for other configurations. Usually, we put in
> `module-info-patch` the bar minimum for allowing the test to compile and
> run. If nevertheless the Surefire plugin wants to add more options, we
> can look for Surefire-specific options. But unless the developer put
> unnecessary stuff in `module-info-patch`, there is few room for removing
> or changing anything defined in that file.
>
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.
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.
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. This is a good way to miss something or keep it
inconsistent from my past experience even if technically it works (as any
solution in IT sadly).
>
> Martin
>
>
