The auto-detection of toolchains could be a nice feature, I'm not familiar with Gradle, but I think Gradle has quite advanced toolchains support that we could use as inspiration. By default, Gradle automatically detects local JRE/JDK installations so no further configuration is required by the user: https://docs.gradle.org/current/userguide/toolchains.html#sec:auto_detection
There are some comments to make Maven download the JDK automatically, and Gradle also has this support (https://docs.gradle.org/current/userguide/toolchains.html#sec:provisioning), but honestly, I think this is really a bad idea, Maven should not handle the download of the JDK as there are too many JDK vendors and many more could come in the future, it's not ideal to force users (even if this feature is optional) to use a specific JDK vendor. On Thu, Jul 28, 2022 at 8:20 AM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > > Le mer. 27 juil. 2022 à 23:37, Guillaume Nodet <gno...@apache.org> a écrit : > > > In response to several comments about toolchains, I wonder if maven should > > provide something a bit more user friendly for maven 4. > > I'm thinking about: > > * extracting the toolchain out of the plugin config (optional) in > > something that could be parsed easily so that mvnd (or the maven script) > > could use the correct JDK directly, > > That would be limited to simple use cases (not those were compilation > > and tests are run with different JDK) > > * a command line tool similar to jenv tool which would be used to > > - set up the initial toolchains (maybe automatically if possible) by > > scanning the system for JDK in known locations > > - list / add / remove / select toolchains > > > > Where it can make the usage nicer, it keeps the installation*s* requirement > and explicit setup on plugins so think it does not solve the overall user > experience. > > However, being able to autoscan well known location (program files, > .sdkman, ....) to gind a matching jdk automatically if settings.xml > contains a flag sounds neat and helpful for existing toolchain usages. > Same for enabling mojo exec to set a java version to use different from the > running java globally (like on an attribute which is not hard to read by a > grep like solution)...but it means mojo executor is enabled to be forked > and stays on java 8 (at least this module). > > > > > Le mar. 19 juil. 2022 à 18:25, Karl Heinz Marbaise <khmarba...@gmx.de> a > > écrit : > > > > > Hi to all, > > > > > > what do you think about using JDK17 as minimum requirement for running > > > the future Apache Maven 4.0.0 ? > > > > > > Kind regards > > > Karl Heinz Marbaise > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > -- > > ------------------------ > > Guillaume Nodet > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
