One hurting step using maven is toolchain setup, and non a command to run every where everytime hurts. So if we can keep exact automatching in it would make it almost friction less IMHO, fine to log a great message when not the case and fail.
Romain Manni-Bucau @rmannibucau <https://x.com/rmannibucau> | .NET Blog <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> Javaccino <https://javaccino.dev/> founder (Java/.NET service - contact via linkedin) Le mar. 4 août 2026, 23:51, Gerd Aschemann <[email protected]> a écrit : > Hi Guillaume, > > I share Matthias' and Maarten's reservation about Maven core "repairing" > a misconfiguration from the shadows -- but the underlying need (building > an older project on a modern JDK) is real and worth solving. I think the > disagreement dissolves if we split it across three responsibilities > instead of putting everything in core: > > 1. Core = diagnose, don't repair. > When the running JDK cannot honour the requested source/release level, > emit one clear, actionable error: the max JDK that supports the level, > and a single command to fix it. That satisfies the "read the error and > act" position without a cryptic javac failure. > > 2. Discovery + selection stays in maven-toolchains-plugin. > The plugin already owns this: `select-jdk-toolchain` discovers and > selects a matching JDK at build time, > `display-discovered-jdk-toolchains` > and `generate-jdk-toolchains-xml` round it out, and 3.3.0 just extended > discovery (asdf, more Windows locations, dedup across env vars). Moving > the discoverer into core would duplicate -- and eventually orphan -- > code the plugin is actively investing in. So to your question in the PR > ("does this make the plugin's discovery redundant?"): I'd argue the > opposite -- keep discovery in one place, the plugin, and have core only > diagnose. > > 3. The real gap none of the current pieces fill: what to do when *no* > compatible JDK is installed at all. > This is where a "propose" (and, opt-in, "provision") capability would > help -- and it belongs in tooling, not core. Concretely, a new goal in > maven-toolchains-plugin that, given the required level, queries the > foojay Disco API for a matching distribution. Default output is > actionable only: an `sdk install java <id>` line and/or a download URL, > plus optionally writing the toolchains.xml entry. Actually downloading a > JDK stays opt-in and checksum-verified. This mirrors what Gradle already > does via its foojay-resolver convention, and foojay is vendor-neutral > (Temurin/Zulu/Liberica/Corretto/...). > > Your mvnup idea fits cleanly on top: mvnup can write the <toolchain> > declaration into the project using that same discover/propose engine, so > the project becomes self-describing for the next contributor. > > For the project-less case (no reactor at hand), the same proposal action > would sit naturally in the Maveniverse Toolbox / mvnx family, which is > already in this space (MWM came up on the #12646 thread). > > Cheers, > Gerd > > > > On 3. Aug 2026, at 23:10, Guillaume Nodet <[email protected]> wrote: > > > > The starting point was to be able to build old projects with Maven 4. > > Would enhancing mvnup to add a toolchain declaration on the project, > > thereby leveraging the m-toolchain-p be a better solution ? > > > > Le lun. 3 août 2026 à 21:10, Maarten Mulders <[email protected]> a > > écrit : > > > >> Hi, > >> > >> Agree with Matthias. Earlier ideas on "troubleshooting common errors > >> through Maven Core" have been rejected for reasons like "people should > >> read the error messages and take corresponding action, rather than Maven > >> trying to diagnose or even repair it". It would be strange to now > >> include such features. I would prefer having clear(er) error messages if > >> that is the source of problem. > >> > >> Also, I see many people blindly ignore warnings, so that would > >> contribute to the scenario that Matthias outlined: "it works on my > >> machine", while in fact I ignored the warning that says Maven switched > >> to an auto-discovered JDK 11 that someone else on my project does not > have. > >> > >> Thanks, > >> > >> Maarten > >> > >> On August 3, 2026 at 17:14, Matthias Bünger wrote: > >>> Hi, > >>> > >>> I'm not convinced in trying to "fix" configuration errors in users > >>> system/project from the "shadows". I think a clear error (and if > >>> possible giving information what's wrong/how to fix) supports the user > >>> more in really fixing the problem. Otherwise we support "it worked on > >>> my machine". I can also think that it's massively increasing > >>> maintenance effort on our side due question why it works here, but not > >>> there or paths to look at on different OS. > >>> > >>> Matthias > >>> > >>> Am 03.08.2026 um 14:18 schrieb Guillaume Nodet: > >>>> Hi all, > >>>> > >>>> I've opened a draft PR for a quality-of-life feature in Maven 4.1.0: > >>>> automatic JDK toolchain selection when the running JDK cannot compile > >>>> the > >>>> project's declared source/release level. > >>>> > >>>> PR: https://github.com/apache/maven/pull/12633 > >>>> > >>>> The problem > >>>> > >>>> When a project declares > <maven.compiler.source>6</maven.compiler.source> > >>>> (or uses <release>, <targetVersion>, or compiler plugin > >>>> <configuration><source>), and you run Maven with JDK 21 — which > dropped > >>>> --source 6 support — the build fails with a cryptic javac error. The > >>>> user > >>>> has to figure out they need to install a compatible JDK and either > >>>> configure toolchains.xml or add the maven-toolchains-plugin to their > >>>> build. > >>>> This is a frequent stumbling block, especially when maintaining older > >>>> projects. > >>>> > >>>> The solution > >>>> > >>>> Maven now automatically detects the incompatibility and searches for a > >>>> compatible JDK — first in configured toolchains (toolchains.xml), > >>>> then by > >>>> lazily discovering JDK installations on the filesystem. If a > >>>> compatible JDK > >>>> is found, it's selected as the compilation toolchain and a warning is > >>>> emitted: > >>>> > >>>> [WARNING] Project requires --source 6 which is not supported by JDK > 21. > >>>> [WARNING] Automatically selected JDK 11 (discovered at > >>>> /usr/lib/jvm/java-11) for compilation. > >>>> > >>>> > >>>> This is a zero-cost feature: the auto-selection logic only runs when > the > >>>> running JDK genuinely cannot handle the project's source level. Normal > >>>> builds are completely unaffected. > >>>> > >>>> Design decisions worth discussing > >>>> > >>>> 1. Filesystem discovery — The discoverer scans well-known locations > >>>> (SDKMAN, IntelliJ .jdks/, Gradle, jEnv, JBang, asdf, mise, OS-specific > >>>> paths like /usr/lib/jvm). Version is read from the JDK release file — > no > >>>> java processes are spawned. This is essentially what > >>>> maven-toolchains-plugin's ToolchainDiscoverer does, but moved into > >>>> core and > >>>> made lazy. Does this make the plugin's auto-discovery redundant? > >>>> Should we > >>>> deprecate it? > >>>> > >>>> 2. Source level detection — We read the source level from multiple > >>>> places > >>>> in priority order: Model 4.1.0 <source><targetVersion>, then > >>>> maven.compiler.release/maven.compiler.source properties, then compiler > >>>> plugin <configuration><release>/<source>. Is this the right > >>>> precedence? Are > >>>> there other places we should check? > >>>> > >>>> 3. "Newest compatible" strategy — When multiple compatible JDKs are > >>>> found, > >>>> we pick the newest one (highest major version that still supports the > >>>> required source level). The rationale is that a newer JDK gives better > >>>> performance and diagnostics. Should this be configurable? > >>>> > >>>> 4. Compat layer — The v3 ToolchainManagerFactory bridge now passes the > >>>> discoverer through, so plugins using the v3 API also benefit. This > felt > >>>> important for the transition period. > >>>> > >>>> CI is green on all platforms (Linux/macOS/Windows × JDK 17/21/25). > >>>> > >>>> Feedback and reviews welcome. > >>>> > >>>> Guillaume > >>>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > > -- > > ------------------------ > > Guillaume Nodet > > -- > Gerd Aschemann (er/he) --- Veröffentlichen heißt Verändern (Carmen Thomas) > +49/173/3264070 -- [email protected] -- https://aschemann.net > >
