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 <ta...@cservenak.net> 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 <garydgreg...@gmail.com> > 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 <ta...@cservenak.net> 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 > > > > > >
