Hi Hervé, +1000 on the philosophy!
On the toolchain support I still fail to see why maven has toolchain anywhere in its code. Look it how it is used: * Tools are generally setup with env variables (JAVA_HOME, JAVA17_HOME, JAVAEA_HOME or alike) * Most plugins able to switch the JDK can switch the executable in their config and use by default ${env.JAVAxx_HOME} or whatever is desired which is the same indirection than toolchain but without the downside to setup a toolchain.xml. Then plugins can just use the binary (optionally PathExt on windows to get the extension) and be it, works really well. So overall I think we could drop toolchain which ultimately still misses a few parts to be complete in terms of env setup and make a shared-executable stronger - likely the future base of exec plugin even if not required. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mer. 21 févr. 2024 à 08:39, Hervé Boutemy <herve.bout...@free.fr> a écrit : > for sure, given the JDK almanach https://javaalmanac.io/jdk/ , we'll have > to update our plans > https://maven.apache.org/developers/compatibility-plan.html > > the approach I'd love to promote is "what do we require to not hurt our > diversity of users when upgrading minimum prerequisites" (and I'm doing it > on my free time because I do care about the diversity of our community) > => let's work on the enablers > > Java prerequisite for Maven core is something, but everything will start > from plugins: that's why we started the plugins "requirement history" > see for example > https://maven.apache.org/plugins/maven-shade-plugin/plugin-info.html > > for a summary on our own plugins, see last column of > > https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-dist-tool/job/master/site/dist-tool-prerequisites.html > > As you can see, not many plugins are not covered yet: who wants to work on > this? > > > Another good item cited is improving decoupling JDK of Maven from JDK to > compile and run tests. > IIRC, Guillaume prepared something about auto-importing available JDKs > from sdkman, which is a great idea: I don't know if this was closed done, > but I suppose other JDK switcher tools should be supported, I'm > particularly interested on knowing what Windows users need > One aspect that I know is not well done is that the MANIFEST in jar > describes JDK release from Maven core, not target: we should probably do > something > Another aspect is that toolchains support has to be enabled in pom.xml: it > would be useful for it to work from just CLI also. > > I'm sure there are other features that would be useful on this: who wants > to work on this? > > > The 2 previous enablers look sufficient to me: any other enabler someone > thinks about? > > And more importantly: who wants to work on it? plan, track progress, > document, explain? > we need community's help to prepare a smooth change: updating our plans > will be a consequence of this preparation > > Regards, > > Hervé > > Le mardi 20 février 2024, 21:49:03 CET Tamás Cservenák a écrit : > > Howdy, > > > > I intentionally used "Maven" here, and not "Maven 4" as I am sure the > > majority of Maven users do not run Maven on the same Java version they > > target with their build. We do not do that either. > > > > Some snippets from Herve (who is the ONLY one doing reproducible checks, > > kudos for that) votes: > > > > Sun, Feb 18, 2024, 9:38 AM > > [VOTE] Release Apache Maven Shade Plugin version 3.5.2 > > Reproducible Build ok: reference build done with JDK 11 on *nix > > > > Wed, Jan 31, 2024, 5:06 AM > > [VOTE] Release Apache Maven JLink Plugin version 3.2.0 > > Reproducible Builds ok: reference build done on *nix with JDK 21 and > umask > > 022 > > > > Mon, Jan 8, 2024, 8:29 AM > > [VOTE] Release Maven Plugin Tools version 3.11.0 > > Reproducible Builds ok: reference build done with JDK 8 on Windows with > > umask > > > > Mon, Dec 18, 2023, 8:59 AM > > [VOTE] Release Apache Maven Compiler Plugin version 3.12.0 > > Reproducible Builds ok: reference build done on *nix with JDK 21 and > umask > > 022 > > > > Mon, Dec 18, 2023, 8:59 AM > > [VOTE] Release Apache Maven Compiler Plugin version 3.12.0 > > Reproducible Builds ok: reference build done on *nix with JDK 21 and > umask > > 022 > > > > Wed, Nov 29, 2023, 8:16 AM > > [VOTE] Apache Maven Build Cache Extension 1.1.0 > > Reproducible Build ok: reference build done on *nix with JDK 11 > > > > Sun, Nov 19, 2023, 5:17 PM > > [VOTE] Release Maven Resolver 1.9.17 > > Reproducible Build ok: reference build done with JDK 21 on *nix with > umask > > 022 > > > > Sat, Oct 21, 2023, 4:34 PM > > VOTE] Apache Maven 4.0.0-alpha-8 release > > Reproducible Build ok: reference build done with JDK 21 on *nix with > umask > > 022 > > > > Mon, Oct 2, 2023, 9:11 AM > > [VOTE] Release Apache Maven 3.9.5 > > Reproducible not fully ok: reference build done with JDK 17 on *nix and > > umask 022 > > > > ==== > > > > This CLEARLY shows the tendency: > > - Michael does releases on Java 8 (on windows!), he is a known "aligner" > > and windows person :) > > - Olivier used the "minimum" required Java version (for build cache). > > - Unsure why Herve used Java 11 for the Shade plugin... I mean, he could > > use 21 but also 8, but he shot for 11 that was EOL at the moment of > release. > > - The rest is 21. > > > > ==== > > > > So, the question for those refusing anything other than Java 8 to _run_ > > Maven (or to revert: for those refusing to run Maven on "latest LTS", > that > > is currently 21): > > WHY? > > > > > > Thanks > > T > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >