I just wanted to note that it is not true that no one is using toolchains, maybe maven devs don't do it ;-)

e.g. github java setup action supports toolchains:

https://github.com/actions/setup-java

and it was added because many users asked for it / requested it.


For me toolchains become *less important* now that Java 9+ has the --target option but now we are back at that maven (+its core plugins) historically is/was stuck at Java 8 ... circle closed :-P

Am 21.02.24 um 08:48 schrieb Romain Manni-Bucau:
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




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Reply via email to