Hi Gerd, Guillaume,
Thank you for your summary and proposal, Gerd. I like the fact that your
proposal focusses on "keeping things where they belong". I think it is a
nice path forward!
Maarten
On 04/08/2026 23:51, Gerd Aschemann wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
