I think this difference during Maven build between compile time JDK vs tests execution time JDK is key for normal users choice. And ease of setup if multiple JDKs are involved (= it's not easy to have configured prerequisites in place)
I suppose good articles showing the full setup to do so would perhaps help normal users to learn how to do such a nice setup: knowledge on the many pieces to do this is not well known something like a good Baeldung article? and with something like the Toolchains improvements to more easily deploy prerequisites, perhaps this could fly Regards, Hervé Le jeudi 1 juin 2023, 18:51:20 CEST Tamás Cservenák a écrit : > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
