Re: [DISCUSS] Maven runtime vs artifact runtime?

[Sylwester Lachiewicz]

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/518201
- 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 
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 
> 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 
> > 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 
> 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
> > > >
> > >
> >
>

Re: [DISCUSS] Maven runtime vs artifact runtime?

[Hervé Boutemy]

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  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  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

Re: [DISCUSS] Maven runtime vs artifact runtime?

[Romain Manni-Bucau]

*Just for the record*.

Toolchain has a great use case IMHO: enable to run on multiple jdk the same
plugin (think surefire/failsafe for ex) without any matrix or CI trick.
The big plus: you test the code runs with all versions you need against the
same binary without side effects. Sometimes it is important cause even
without API breakage the JRE has bugs you want to cover.
That said agree most projects will just not use that (nor will), it is a
bit like using some particular lib, it fits a particular need.
But using toolchain just cause the maven requisite goes too fast sounds
like making the entry cost higher for users, not only in installation but
in understanding and debugging too + will break all ToolProvider/embedded
cases.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mar. 6 juin 2023 à 02:05, Henning Schmiedehausen <
henn...@schmiedehausen.org> a écrit :

> 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 
> 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 
> > 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 
> 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
> > > >
> > >
> >
>

Re: [DISCUSS] Maven runtime vs artifact runtime?

[Henning Schmiedehausen]

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  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 
> 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  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
> > >
> >
>

Re: [DISCUSS] Maven runtime vs artifact runtime?

[Henning Schmiedehausen]

I always assumed that Java versions are a solved problem in JDK 9+ with
'-release' which creates bytecode for the targeted JDK and even ensures
that no classes or methods from the JDK are used that are not supported in
that version.

There is a desire for "everything must be the same" that I am not sure I
understand. I ship a lot of open source and compile everything with "latest
LTS" to Java 8 or Java 11. I have never seen a user complain that the
resulting artifacts do not work.

So why do I need that support? I am genuinely curious. It seems that there
is something that I am missing or are too naive about. What is the problem
that toolchains (in maven or gradle) solve that I am not aware of?

-h


On Thu, Jun 1, 2023 at 5:12 AM Christoph Läubrich 
wrote:

>  > 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
>
>

Re: [DISCUSS] Maven runtime vs artifact runtime?

[Tamás Cservenák]

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  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  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
> >
>

Re: [DISCUSS] Maven runtime vs artifact runtime?

[Gary Gregory]

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  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
>

Re: [DISCUSS] Maven runtime vs artifact runtime?

[Jeremy Landis]

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 
Sent: Thursday, June 1, 2023 8:20:13 AM
To: Maven Developers List 
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=05%7C01%7C%7C22d12e2342394f27ef8b08db629a9c34%7C84df9e7fe9f640afb435%7C1%7C0%7C638212188408929080%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=1YbaEsP6uVSBxYMfpdG61loWoH3DfYrPl9G9jAF49Ok%3D=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 
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=05%7C01%7C%7C22d12e2342394f27ef8b08db629a9c34%7C84df9e7fe9f640afb435%7C1%7C0%7C638212188408929080%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=vOWuj2rurVip7qPHg3wm1jRs8VDB0a8hhTbLHCLyDE0%3D=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

Re: [DISCUSS] Maven runtime vs artifact runtime?

[Tamás Cservenák]

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://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 
wrote:

>  > 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
>
>

Re: [DISCUSS] Maven runtime vs artifact runtime?

[Romain Manni-Bucau]

Well, Guillaume's work kind of solves that...but still, even with gradle,
toolchains are a nightmare for most users so it is quite common to end with
the same jdk to build and run.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 1 juin 2023 à 14:12, Christoph Läubrich  a
écrit :

>  > 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
>
>

Re: [DISCUSS] Maven runtime vs artifact runtime?

[Christoph Läubrich]

> 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

Re: [DISCUSS] Maven runtime vs artifact runtime?

[Romain Manni-Bucau]

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  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le jeu. 1 juin 2023 à 14:02, Tamás Cservenák  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
>