That's how we also our ci and local environment. On prvarte laptops we use latest LTS and ea Java versions to build and compile but use gha to check with other combinations. Sometimes it's a bit huge https://github.com/apache/maven-compiler-plugin/actions/runs/5182017777 - 3 latest Maven versions ("3.3.9", "3.8.8", "3.9.2") - latest LTS Java "8", "11", "17" and non LTS "20" - also people may use JDK from different vendors, previously not everything was working in same way "temurin", "zulu", "microsoft", "adopt-openj9"
This results in around 120 runs donated by Azure/Microsoft resources (Thx!) Then we do not run tests on Java 21-ea - to help with early bug detection in Java or plugins - this would add around 6 more runs. Believe me or not, but soon after Java 21 release someone will raise a bug report if something isn't working (and that's good). Recent bugs like https://github.com/google/error-prone/issues/3895 affected also our pipeline (spotless plugin) - we can learn and adjust our setup. "We" means The Community - everyone who can open PR and help improve our products so everyone can benefot from it. Sylwester wt., 6 cze 2023 o 02:05 Henning Schmiedehausen <henn...@schmiedehausen.org> napisał(a): > 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 > > > > > > > > > >
