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 >
