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
