Hi Tamas, Think we have two kind of users:
* toolchain ones (probably minority) -> most plugins are okish there * contextual ones (use the build jdk to run maven and build apps) So overall I think we are quite targetting that already. In terms of compat matrix, I agree it is werid to not build on one OS with one Java version and test against other OS and version since it is the only case which will happen at release time + it implies some lost time but not sure how easy it would be to have a downstream build to replay the tests only on our CI. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le jeu. 1 juin 2023 à 14:02, Tamás Cservenák <ta...@cservenak.net> a écrit : > 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 >
