Re: Status of JPMS support and "module-info-patch" proposal

2025-04-15 Thread Martin Desruisseaux
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 as a tedious workaround until the compiler plugin is updated.

Re: Status of JPMS support and "module-info-patch" proposal

2025-04-15 Thread Romain Manni-Bucau
Le mar. 15 avr. 2025 à 13:03, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2025-04-15 à 11 h 53, Romain Manni-Bucau a écrit : > > >> If we add a new mechanism for allowing other plugins to access the > >> configuration of the Java compiler plugin, it would make plugin > >

Re: Status of JPMS support and "module-info-patch" proposal

2025-04-15 Thread Martin Desruisseaux
Le 2025-04-15 à 11 h 53, Romain Manni-Bucau a écrit : 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.

Re: Status of JPMS support and "module-info-patch" proposal

2025-04-15 Thread Romain Manni-Bucau
Le mar. 15 avr. 2025 à 11:14, Martin Desruisseaux < martin.desruisse...@geomatys.com> 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 yo

Re: Status of JPMS support and "module-info-patch" proposal

2025-04-15 Thread Martin Desruisseaux
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 optio

Re: Status of JPMS support and "module-info-patch" proposal

2025-04-14 Thread Romain Manni-Bucau
Le mar. 15 avr. 2025 à 01:10, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit : > Le 2025-04-14 à 19 h 43, Romain Manni-Bucau a écrit : > > > This is not always true, the common case is to inject a mock of an > external > > service to test an algorithm or alike. > > If the service

Re: Status of JPMS support and "module-info-patch" proposal

2025-04-14 Thread Martin Desruisseaux
Le 2025-04-14 à 19 h 43, Romain Manni-Bucau a écrit : This is not always true, the common case is to inject a mock of an external service to test an algorithm or alike. If the service is a public interface, there is no need to patch a module for creating mocks. I'd like all the JPMS to st

Re: Status of JPMS support and "module-info-patch" proposal

2025-04-14 Thread Romain Manni-Bucau
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 ("with

Re: Status of JPMS support and "module-info-patch" proposal

2025-04-14 Thread Martin Desruisseaux
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 on

Re: Status of JPMS support and "module-info-patch" proposal

2025-04-14 Thread Romain Manni-Bucau
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

Re: Status of JPMS support and "module-info-patch" proposal

2025-04-14 Thread Martin Desruisseaux
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 sin

Re: Status of JPMS support and "module-info-patch" proposal

2025-04-14 Thread Romain Manni-Bucau
Hi, maybe a bit out of context but some work was done to make it possible to define options within the pom, why wouldn't it fit better than a hacky file which is actually just an internal trick of some maven plugins but not all? It would be like dependencies for a JVM. Assuming to assign them a "s

Re: Status of JPMS support and "module-info-patch" proposal

2025-04-14 Thread Martin Desruisseaux
Le 2025-04-14 à 12 h 49, Gary Gregory a écrit : "The ".txt" extension is because this file is not standard Java (proposals for better extension are welcome)." How about ".mvn" or ".maven" to make it clear that this file exists for Maven's purpose and is not documentation, which is what ".txt"

Re: Status of JPMS support and "module-info-patch" proposal

2025-04-14 Thread Gary Gregory
"The ".txt" extension is because this file is not standard Java (proposals for better extension are welcome)." How about ".mvn" or ".maven" to make it clear that this file exists for Maven's purpose and is not documentation, which is what ".txt" feels like to me. Gary On Mon, Apr 14, 2025, 05:4

Status of JPMS support and "module-info-patch" proposal

2025-04-14 Thread Martin Desruisseaux
Hello all The compiler plugin has a pull request which is ready for the support of multi-release projects and modular projects defined by the elements introduced in POM 4.1.0. However, the changes are a bit large and I'm not sure how to proceed for review, as it would be a lot of work for re