> Does Maven miss some features
Just look at how gradle support toolchains:
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://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
