Without delving into every detail, one concern I have is the inability to use the <release> option alongside <source> and <target>, MCOMPILER-582 <https://issues.apache.org/jira/browse/MCOMPILER-582> was a nice improvement, but I'm not sure if that behavior remains. In any case, in my opinion, relying on an empty <source/> <target/> workaround isn't ideal, as it compromises usability.
Another point worth mentioning is MCOMPILER-542 <https://issues.apache.org/jira/browse/MCOMPILER-542>. While I understand the goal of dropping dependencies, the regression it introduces for reproducible builds in modular projects is concerning. The recommended workaround of compiling with Java 22 or later isn’t practical for every project, especially considering that not all projects are ready to adopt Java 22, and as Hervé pointed out, even though JDK 22 contains the fix, the general expectation is that Reproducible Builds releases will be based on the next LTS version. Relying on a non-LTS compiler to build releases for Maven Central doesn't align with best practices. While I appreciate the modernization efforts for the maven-compiler-plugin, we need to balance this with user experience considerations. Removing features without addressing these concerns could detract from the overall usability of the plugin. I understand this can be part of an incremental effort, but ensuring a smooth UX is crucial to avoid user frustration over seemingly small issues. +0 (nb) On Wed, Oct 23, 2024 at 4:40 PM Martin Desruisseaux < martin.desruisse...@geomatys.com> wrote: > Le 2024-10-23 à 16 h 22, Ralph Goers a écrit : > > > What is the easiest way to determine what has been changed? When I was > > working on Log4j’s JPMS support Maven’s handling of JPMS frequently > > caused problems and forced us to do some things I consider kind of ugly. > > > The main changes are described there, especially the 2 first points > ("Incompatible changes" and "Changes in compiler parameters"). The rest > can easily be ignored: > > https://github.com/Geomatys/maven-compiler-plugin/wiki > > If accepted, above-cited two points would be ported to the APT format > for the plugin site. > > If anything break e.g. with Log4J, we will either fix the regression or > document the changes with proposed alternatives. But it implies that > there is a risk that the compiler plugin 4.0.0-beta-2 breaks some builds > and that we need a couple of beta releases before to resolve the issues. > > Martin > >
