On github I use the matrix across nearly everything just to show to users it works on various versions. It has nothing to do at all with what is used to release it. I use only jdk 17 on windows currently to release items on github.
For my paying job. We don't have that level of resources available so jave 17 is it to target 8 or 11 or 17. We don't use toolchains as IMO it's unnecessary. We use the release tag and enforcer. Got rid of animal sniffer long ago. And given many plugins now require java 8. We don't bother with 8 anymore on repos I work on github outside of one that have this insistence in proving 8 works. But again no toolchain there either. Just make GHA build it then pull jdk and run integration tests proving 8 works. Sent from my Verizon, Samsung Galaxy smartphone Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Tamás Cservenák <ta...@cservenak.net> Sent: Thursday, June 1, 2023 8:20:13 AM To: Maven Developers List <dev@maven.apache.org> Subject: Re: [DISCUSS] Maven runtime vs artifact runtime? Howdy, But AFAIK the toolchain is similar, all you need is to setup maven-toolchains-plugin once and done, so is "central" as well, no? https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmaven.apache.org%2Fguides%2Fmini%2Fguide-using-toolchains.html&data=05%7C01%7C%7C22d12e2342394f27ef8b08db629a9c34%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638212188408929080%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=1YbaEsP6uVSBxYMfpdG61loWoH3DfYrPl9G9jAF49Ok%3D&reserved=0<https://maven.apache.org/guides/mini/guide-using-toolchains.html> What do you mean by "no need to configure here and there"? You mean toolchains.xml? Or POM changes? As Romain said, Guillaume made a nice change related to that.... On Thu, Jun 1, 2023 at 2:12 PM Christoph Läubrich <m...@laeubi-soft.de> wrote: > > Does Maven miss some features > > Just look at how gradle support toolchains: > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.gradle.org%2Fcurrent%2Fuserguide%2Ftoolchains.html&data=05%7C01%7C%7C22d12e2342394f27ef8b08db629a9c34%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638212188408929080%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vOWuj2rurVip7qPHg3wm1jRs8VDB0a8hhTbLHCLyDE0%3D&reserved=0<https://docs.gradle.org/current/userguide/toolchains.html> > > That's all shows what maven refuses to support and leaving people think > its easier to use the same JVM "from beginning to end": > > 1) First class declarative central configuration (no need to configure > it here and there) > 2) automatic discovery of installed toolchains > 3) Support for automatically download if a matching one if not found > > All this has nothing to do with that is is *possible* to do so in maven > as well, it is just not *convenient* to do so and as its is not *easy* > as well (you can just miss a thing) people are skeptical and try to "be > sure" by using the same JVM from start-to-end... > > > Am 01.06.23 um 14:00 schrieb Tamás Cservenák: > > 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnielsbasjes%2FToolChainsInCiBuilds&data=05%7C01%7C%7C22d12e2342394f27ef8b08db629a9c34%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638212188408929080%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zLjPt3pJ54BQYKfbzb4wBErMbNeG4AbHstto4Df4Smc%3D&reserved=0<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 > >
