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? > I think it's an oversight, I don't really see why it would not be thread safe. > Also I am missing a parameter to provide a search path. Might come in > handy in CI environments like Jenkins. > Yes, that would be a good addition. The discovery mechanism uses hard coded heuristics and improvements would be welcomed. Or customization... > 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 > > -- ------------------------ Guillaume Nodet
