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
>
>
