*Just for the record*. Toolchain has a great use case IMHO: enable to run on multiple jdk the same plugin (think surefire/failsafe for ex) without any matrix or CI trick. The big plus: you test the code runs with all versions you need against the same binary without side effects. Sometimes it is important cause even without API breakage the JRE has bugs you want to cover. That said agree most projects will just not use that (nor will), it is a bit like using some particular lib, it fits a particular need. But using toolchain just cause the maven requisite goes too fast sounds like making the entry cost higher for users, not only in installation but in understanding and debugging too + will break all ToolProvider/embedded cases.
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 6 juin 2023 à 02:05, Henning Schmiedehausen < [email protected]> a écrit : > Agreed, that is one way to do that, but it seems to me that this is a > CI/integration test issue, not a build issue per se. > > We do the same thing in Jdbi: Build with the LTS JDK, then test against 8, > 11, 17, current Java release: > https://github.com/jdbi/jdbi/blob/master/.github/workflows/ci.yml > > Personally, I have zero interest in installing many JDKs on my laptop > (hah!) and am happy to let the CI manage those. It's its job after all. :-) > > -h > > > On Thu, Jun 1, 2023 at 9:51 AM Tamás Cservenák <[email protected]> > wrote: > > > Howdy, > > > > define 3 Java versions in my toolchains.xml, and then add 3 executions > for > > surefire like here? > > > > > https://maven.apache.org/surefire/maven-surefire-plugin/examples/toolchains.html > > > > Thanks > > T > > > > > > On Thu, Jun 1, 2023 at 6:39 PM Gary Gregory <[email protected]> > > wrote: > > > > > I claim it is not wasteful to run unit tests on Java 8, 11, and 17, > which > > > usually is the longest and most resource intensive part of a build. > > > > > > How would you do that were it not for a GitHub matrix? > > > > > > Gary > > > > > > On Thu, Jun 1, 2023, 08:01 Tamás Cservenák <[email protected]> > wrote: > > > > > > > Howdy, > > > > > > > > From recent discussions I see an interesting pattern: it seems that > > > people > > > > (even our PMCs) are using Maven in a way that is making sure that > "same > > > > Java version" (I guess vendor + version) is used from "beginning" to > > > "end". > > > > > > > > And "beginning" here means BUILDING (think workstations and CI and so > > > on), > > > > while "end" means PRODUCTION (deploying the stuff into production). > > > > > > > > Why is that? > > > > > > > > We all know that even before this "speedup" of Java releases (so to > > say, > > > up > > > > to Java 8) we did put extra effort into supporting this (running > Maven > > on > > > > different Java versions and producing another bytecode output). One > > can: > > > > - use source/target compiler flags + animal sniffer (if on Java 8 or > > > older) > > > > - use release compiler flag (if Java9+ used) > > > > - use toolchains > > > > > > > > Why does any of these above "does not work" for those "aligning Java > > from > > > > beginning to end"? > > > > > > > > With today's tools like sdkman, jenv, homebrew, jbang, mvnw (and who > > > knows > > > > what) it is REALLY HARD to miss the automation of getting JDKs and > > tools > > > > (and keeping them up to date!!!) on workstations and CIs (deployment > > not > > > > counted here, but hopefully it is automated as well). > > > > > > > > Another point is that upcoming Maven 4 has tremendous improvements > > > > targeting toolchains. > > > > > > > > Finally, a bit of digression, but very much related thing: as Niels > > > > showcased on other thread in > > > > https://github.com/nielsbasjes/ToolChainsInCiBuilds > > > > > > > > The CI "matrix" build's Java version part can be moved into Maven > > itself. > > > > Personally, I always hated "matrix" as they explode very easily (size > > > wise) > > > > but in MOST cases they really just "warm the oceans" (from HB) and do > > not > > > > do anything useful. I do keep _matrix useful_ for OS variations, but > to > > > > rebuild the same commit over and over with Java8, Java11, Java17 only > > to > > > > "be sure" it will work, is really an overkill (and very wasteful). > The > > > > added beauty of applying this pattern is that one can perform the > whole > > > > build and testing (using different Javas) even on their own > > workstations. > > > > > > > > Does Maven miss some features (aside from those above) to make it > > > possible > > > > for those "aligning" Java versions to move? > > > > > > > > Thanks > > > > T > > > > > > > > > >
