Hi, The discovery uses JAVA_xx_HOME environment variables which is often the way CI are setting up the paths - ack not on jenkins if not done manually but it is not a bad practise. I assume adding a property to configure yet another search path ( https://github.com/apache/maven-toolchains-plugin/blob/master/src/main/java/org/apache/maven/plugins/toolchain/jdk/ToolchainDiscoverer.java#L421) is doable but I'm not sure it would enable any real use case except manual setups. On jenkins the common practise for JDK installers is to write the toolchain and provide it to jobs for a working out of the box experience so maybe your setup is not complete on this part?
About thread safety it is mainly about writing the toolchain discovery result xml file so the easiest is to run it alone with a profile of your project then ignore it totally for the actual build. It is rather a good practise since the discovery is not free when you have a lot of jdk installed (multi vendors+versions validation for ex). Here again we can likely make it pomless to ease CI integration if it would help or lock a sibling file but your use case is already covered IMHO. So while I think both requests can be done it ca be worth investing a few minutes tuning the jenkins usage to see if normalizing the setup will not give more benefit than updating tools - not everything uses toolchain and several external plugins still need explicit binary path so having the JAVA_xx_HOME variables defaulting to JAVA_HOME in the pom is always a better practise IMHO. Hope it makes sense 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> Le mar. 4 févr. 2025 à 09:05, Thomas Reinhardt <tho...@reinhardt.com> a écrit : > > Interesting, I was not aware of the new discovery mechanism. > > Unfortunately the most interesting goal "select-jdk-toolchain" is not > marked threadsafe. Was that a conscious decision or just easier to > implement? > > Also I am missing a parameter to provide a search path. Might come in > handy in CI environments like Jenkins. > > Any opinions on the above two points? Otherwise I would just open issues > for those. > > > -Thomas > > > On 03/02/2025 08:05, Guillaume Nodet wrote: > > The toolchains discovery has been released a few months ago: > > > > > https://maven.apache.org/plugins/maven-toolchains-plugin/toolchains/jdk-discovery.html > > This is also usable in Maven 3.x. > > > > I think that should cover your use case. > > The enforcer check does not really need to be performed because the > > toolchain selection > > will ensure that the selected toolchain matches the input range. > > > > Le lun. 3 févr. 2025 à 07:12, Mikko Johannes Koivunalho < > > mikko.koivuna...@iki.fi> a écrit : > > > >> Hi, > >> > >> I am forwarding this message to Maven Developer List. > >> > >> Before getting to any development, I'd like to know more about planned > >> Maven4 improvements in the area of toolchains. > >> > >> Thank you. > >> > >> > >> Sincerely, > >> Mikko Koivunalho > >> > >> On 02/02/2025 19:28, Tamás Cservenák wrote: > >>> Howdy, > >>> > >>> TBH, I never understood why toolchains are not ALWAYS used > >>> with one (always) available toolchain, the Java that runs Maven > >>> itself, so this would be your fallback. > >>> > >>> Re enforcer, yes, probably we need new rules that would behave > >>> as you describe. > >>> > >>> Hence, yes, this would be a good direction. > >>> > >>> OTOH, for Maven4 we do have some improvements in this area, > >>> like auto discovery, so any contribution is welcome! > >>> > >>> Thanks > >>> T > >>> > >>> On Sun, Feb 2, 2025 at 6:35 PM Mikko Johannes Koivunalho > >>> <mikko.koivuna...@iki.fi> wrote: > >>>> Hi, > >>>> > >>>> I work with many Maven projects which require building with different > >>>> JDKs: Java 8, Java 11, Java 17, and so on. I have all these installed > >>>> side by side in my build machine. > >>>> > >>>> Maven Toolchains plugin is very helpful because it prevents me from > >>>> being forced to reconfigure environment variable JAVA_HOME when I move > >>>> between Maven projects. > >>>> > >>>> However, for those who only use one of those projects, configuring the > >>>> toolchains and JDKs is too complicated. They have their Java already > >>>> configured to use the correct JDK. > >>>> > >>>> It would be convenient if Maven Toolchains plugin had a fallback mode: > >>>> when the file .m2/toolchains.xml is not present, i.e. the toolchains > are > >>>> not configured, Maven Toolchains plugin would simply fall back to use > >>>> the same Java as Maven itself uses. > >>>> > >>>> Maven Toolchains plugin could have a setting to allow the fallback. By > >>>> default, the fallback would not be allowed. This is the behavior now. > >>>> > >>>> > >>>> Even when using toolchains, I am also using Maven Enforcer rule > >>>> RequireJavaVersion to limit the range of usable Java versions. This > rule > >>>> only tracks the version of the Java runtime Maven itself is using so > it > >>>> is not compatible with Maven Toolschains. > >>>> > >>>> To work with Maven Toolchains plugin and remain backwards compatible, > >>>> Maven Enforcer would need a new rule, maybe > >>>> "RequireJDKVersion", "RequireToolchainJavaVersion" or > >>>> "RequireJavaCompilerVersion". It would also have to work with the > >>>> fallback mode as described above. > >>>> > >>>> > >>>> Would the above be the right direction to develop Maven Toolchains? > >>>> Thanks for all comments. > >>>> > >>>> > >>>> Sincerely, > >>>> Mikko Koivunalho > >>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >>>> For additional commands, e-mail: users-h...@maven.apache.org > >>>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >>> For additional commands, e-mail: users-h...@maven.apache.org > >>> > >>> > >> -- > >> Mikko Koivunalho > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
