Le mer. 21 févr. 2024 à 09:07, Hervé Boutemy <herve.bout...@free.fr> a écrit :
> ok, you want to contribute on decoupling JDK of Maven vs JDK of compiler > and > tests: perhaps we'll need to open a separate discussion to avoid hijacking > the > global plan, but let's have one roundtrip > Just to clarify: I don't want but for the rare cases you want to do it you can already. > > scenario is: I use JDK 21 to run Maven, but I need JDK 8 to run my unit > and > integration tests > of course, i have both JDKs on my machine > Assuming you have JAVA8_HOME setup you set <jvm>${env.JAVA8_HOME}/bin/java</jvm> in surefire and be it. > > I see how I can manually configure toolchain.xml, modify pom.xml etc... to > do > that: it works, it's cumbersome > > How does "dropping toolchains" help? > Does not help, read it the opposite way, "toolchain does not help". > > Defining a common plan will probably require a dedicated discussion, > perhaps > some wiki pages, perhaps some meeting between people interested to have > more > live ideation before sharing proposal on the ML (which is necessary for > wider > community discussion) > Sure, my point was not to create a debate on that now, just that we should probably not see toolchain as a solution cause it hurts more it helps. > > Le mercredi 21 février 2024, 08:48:43 CET Romain Manni-Bucau a écrit : > > 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/jo > > > b/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 > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >