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 > > >
