Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Romain Manni-Bucau]

Le dim. 24 juil. 2022 à 20:56, Guillaume Nodet  a écrit :

> Le dim. 24 juil. 2022 à 08:54, Romain Manni-Bucau 
> a
> écrit :
>
> > Le sam. 23 juil. 2022 à 21:05, Enno Thieleke <
> enno.thiel...@holisticon.de>
> > a écrit :
> >
> > > Fwiw:
> > >
> > > Romain, I think you're exaggerating. The answer is, like in most cases:
> > > "it depends".
> > >
> > > Most people, we're most likely talking 95-99% here, will happily use
> JDK
> > > 17 with Maven 4.
> > >
> >
> > I would lower the figure - keep in mind 95-99% of people also uses libs
> and
> > are affected by what I described - but agree "most" would see it...at the
> > cost of configuring toolchain and even just the test/compiler version in
> > the pom which breaks our convention over config core design IMHO.
> >
> > So until we change our design to isolate all our core code and mojo run
> > from contextual java version (most mojo are not toolchain friendly, this
> > requires a mojo executor evolution to make the ecosystem functional), and
> > likely means we can:
> >
> > 1. Have background jvm runners (reusable) to avoid the cold perf pitfall
> of
> > toolchain
> >
>
> Aren't you just describing mvnd ?  mvnd is compiled to native already.
>

But mvnd does not coordinates N jvms to make toolchain fast. Mvnd solves
mvn cold startup issue but not the same pitfall for mojo forks (needs to
fake java exec to replace java by a java client like mvnd one).


>
> > 2. Toolchain functional for all mojo without any mojo change
> > 3. A global property to limit the configuration for all mojo
> >
> > I dont think it would work well in practise.
> >
> > I also dont want to exclude 50% of users (8+11) just cause we think we
> > would maybe gain from that - there is very few valid reason in terms of
> > compilation to do that on our side.
> >
> > Side note: technically, if reached, it means we can make mvn a native
> > binary with graalvm and run mojo in java runner so java wouldnt be a real
> > constraint for us/users but this has high impacts in terms of design and
> > code update requirements.
> >
> >
> > > Some people might need to compile for lower sources and targets, but
> > > running tests for those builds in JDK 17 instead of, let's say 11,
> _will
> > > suffice in most cases_.
> > >
> > > Yes, there will be edge cases where people will be forced to use
> > different
> > > JDKs at least for tests, some even for builds. But that's possible, so
> > they
> > > won't get left behind.
> > >
> > > Regarding mvnd: It's not a silver bullet. It never was and it never
> will
> > > be. Whenever a build spawns new JVMs (for tests or other tasks), it
> > doesn't
> > > benefit from mvnd anymore (in as much as it would without spawning new
> > > JVMs).
> > >
> > > To not use the latest (LTS) JDK in order to "better" support the 1-5%
> of
> > > the Maven users, who're still using obsolete JVMs (I'm obviously
> > referring
> > > to Karl's assumption, which I agree with), would be a kick in the teeth
> > of
> > > all Maven developers, who finally want to embrace the present (not even
> > the
> > > future).
> > >
> > > Long story short, +1 for JDK 17 as minimum for Maven 4.
> > >
> > > Kind regards,
> > > Enno
> > >
> > > 
> > > From: Romain Manni-Bucau 
> > > Sent: Saturday, July 23, 2022 6:55 PM
> > > To: Maven Developers List 
> > > Subject: Re: Question - JDK Minimum of future Apache Maven 4.0.0
> > >
> > > Le sam. 23 juil. 2022 à 17:25, Benjamin Marwell 
> a
> > > écrit :
> > >
> > > > No, 2 JDKs are not required by default. Only if you use
> --release={<17}
> > > and
> > > > don't trust running tests on 17 are the same as running tests on 8.
> > > > Yes, there are changes (certificates, XML libs, rhino, etc).
> > > >
> > >
> > > As explained it means you dont write a single test or dont care of the
> > test
> > > results so yes it needs 2 jdk.
> > >
> > >
> > >
> > > > So, for most projects that's probably not needed. For those who think
> > it
> > > is
> > > > needed, I don't have a lot of pity. But it will be a requirement for
> > > quite
> > > > a few commercial projects, like Containers (JavaEE, as they will need
> > to
> > > be
> > > > Java 8 as long as 2030ish due to extended support contracts).
> > > >
> > > > That said, I'm still thinking Java 17 will be a sane default.
> > > >
> > > >
> > > > On Sat, 23 Jul 2022, 10:50 Delany, 
> wrote:
> > > >
> > > > > Using mvnd with toolchains doesn't improve the situation, in fact
> > > > > toolchains seem to invalidate any benefit of using mvnd.
> > > > > Even if this was resolved, is it fair to require mvnd?
> > > > > Delany
> > > > >
> > > > >
> > > > > On Sat, 23 Jul 2022 at 10:17, Mark Derricutt 
> > wrote:
> > > > >
> > > > > >  Is that due to cold starting the JVM each time?
> > > > > >
> > > > > > I wonder if mvnd supports toolchains effectively?  Or if that
> could
> > > be
> > > > an
> > > > > > avenue to try.
> > > > > > --
> > > > > > "Great artists are extremely selfish and arrogant 

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Mark Derricutt]

 On 25/07/2022 at 10:38:34 AM, Michael Osipov  wrote:

> ...and their justification is? Don't tell me they will use Java 11
> features to sort a POM? Joke.



None -
https://github.com/Ekryd/sortpom/commit/080797dfee00b29839c2975348b5627911e2f5ad#commitcomment-78648749

-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

Re: [VOTE] Release Maven Site Plugin version 4.0.0-M3

[Olivier Lamy]

+1

On Mon, 25 Jul 2022 at 02:59, Michael Osipov  wrote:

> Guys,
>
> please take a moment to review...
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Michael Osipov]

Am 2022-07-25 um 00:26 schrieb Slawomir Jaranowski:

Hi

Very long discussion ... so my penny to the latest ones

- I don't believe that jdk 17 gives us more contributors ... The problem is
somewhere else - another discussion can be about it
- I am afraid that users can have more problems using jdk 17 + toolchains
- using jdk 17 as target doesn't give us any boost with fixing bugs, we
have many bugs ...

I'm for  jdk 8 as a target for Maven Core, in some of the important pieces
we can use the milti release feature.


Thank you, this is exactly what we suffer from. You have been fantastic, 
bus exhausting work which won't be easier with any newer Java version. 
In fact, users will never contribute what you contribute. They throw an 
issue at us and expect us to solve it. Free, idiot support.


M

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Slawomir Jaranowski]

Hi

Very long discussion ... so my penny to the latest ones

- I don't believe that jdk 17 gives us more contributors ... The problem is
somewhere else - another discussion can be about it
- I am afraid that users can have more problems using jdk 17 + toolchains
- using jdk 17 as target doesn't give us any boost with fixing bugs, we
have many bugs ...

I'm for  jdk 8 as a target for Maven Core, in some of the important pieces
we can use the milti release feature.

Of course we should be able to execute with the latest jdk.

niedz., 24 lip 2022 o 23:00 Michael Osipov  napisał(a):

> Am 2022-07-24 um 22:54 schrieb Andreas Sewe:
> > On 20.07.22 15:39, Karl Heinz Marbaise wrote:
> >> On 20.07.22 13:04, Romain Manni-Bucau wrote:
> >>>  > There is no need to use toolchain to run your build with JDK17 and
> >>>  > create code for Java 8... you can use --release 8
> >>>  > (8)...
> >>>  >
> >>>  > No toolchain needed.
> >>>
> >>> So you run tests with java 17? This is not what you want if your prod
> is
> >>> in java 8, you can still get surprises so you need toolchain in your
> >>> build (same happen for compilation since bytecode is not 1-1, only
> >>> signatures).
> >>
> >> First what kind of surprises?
> >>
> >> Second can you show an example of different bytes codes?
> >
> > Just a regular Maven user here, but I'll give you an example, Karl
> > Heinz, where testing against different Java versions was necessary to
> > avoid shipping a blocker bug -- even though the bytecode didn't differ
> > at all.
> >
> > Some context: We maintain a couple of plug-ins for different IDEs
> > (Eclipse, IntelliJ, NetBeans). Each plugin needs to be compatible with a
> > whole range of IDE versions, as not all our users (can) use the latest
> > and greatest. And different IDE versions usually mean different Java
> > requirements, too.
> >
> > In the case of the NetBeans plug-in (the same holds for Eclipse and
> > IntelliJ, but these are build with Gradle and Maven+Tycho, respectively,
> > rather than with plain Maven) this means that the plug-in needs to
> > target Java 8 at the lower end, as older versions of NetBeans don't even
> > run on the latest version of Java. Hence, we compile against Java 8.
> >
> > However, we *also* occasionally test against newer versions of Java
> > (e.g., in our nightly builds) to catch errors like the following:
> >
> > The plug-in classloader of NetBeans [1] (and IntelliJ [2], FWIW) does
> > not support multi-release JARs, which means that the following LOG4J2
> > statement fails when running on Java 9 or later.
> >
> >  private static final Logger LOGGER = LogManager.getLogger();
> >
> > As the plug-in classloader does not support the multi-release
> > capabilities of the Log4J2 JAR, we end up in the Java 8 variant of
> > getLogger(), which no longer works under newer versions of Java. The
> > resulting ExceptionInInitializerError completely breaks our plug-in, but
> > this luckily has been found during testing -- running the tests with
> > Java 9 or later.
> >
> > I hope this example was useful to the discussion at hand.
> >
> > Now, at the moment we run Maven itself with Java 17 (as it speeds up our
> > builds) and use toolchains to compile *and* test against Java 8. During
> > our nightly build, however, we also pass in a system property which
> > selects a different toolchain (ATM, Java 11).
> >
> > This works, but is not ideal, as our nightly sanity build not only tests
> > against Java 11 but also builds against it; both maven-compiler-plugin
> > and maven-surefire-plugin use the *same* toolchain. Unfortunately, this
> > means that we don't have a guarantee that the test against Java 11 use
> > the same bytecode that we ship, since the nightly build compiles with
> > the Java 11 but we have to ship the code compiled against Java 8 (i.e.,
> > our lowest denominator).
> >
> > In an ideal world, our setup would look like this:
> >
> > - mvn: Runs with Java 17
> > - maven-compiler-plugin: --release 8
> > - maven-surefire-plugin: a Java 8/11/17 toolchain, selected by system
> >  property
> >
> > At the moment, we are not there yet, as we cannot use --release, as
> > there cannot be separate toolchains for compilation and test. If that
> > were to change with Maven 4, that would be great, of course.
> >
> > Hope this helps.
>
> As I said. Such an example and a move to Java 17 would cause just
> friction without any lubricant.
>
>

-- 
Sławomir Jaranowski

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Michael Osipov]

Am 2022-07-25 um 00:19 schrieb Mark Derricutt:

  For what it’s worth - I’m now finally starting to see a lot more libraries
updating their minimum supported versions to a mix of 11 and 17.

And now also encountering mojo updates ( sort pom hit he recently ) that
updated their minimum to 11 - and sadly all these changes are under
minor/patch versions which irk me beyond something ;p


...and their justification is? Don't tell me they will use Java 11 
features to sort a POM? Joke.

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Mark Derricutt]

 For what it’s worth - I’m now finally starting to see a lot more libraries
updating their minimum supported versions to a mix of 11 and 17.

And now also encountering mojo updates ( sort pom hit he recently ) that
updated their minimum to 11 - and sadly all these changes are under
minor/patch versions which irk me beyond something ;p

Mark

On 25/07/2022 at 9:00:21 AM, Michael Osipov  wrote:

> I would lower the figure - keep in mind 95-99% of people also uses libs and
> are affected by what I described - but agree "most" would see it...at the
> cost of configuring toolchain and even just the test/compiler version in
> the pom which breaks our convention over config core design IMHO.
>


-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Michael Osipov]

Am 2022-07-24 um 22:54 schrieb Andreas Sewe:

On 20.07.22 15:39, Karl Heinz Marbaise wrote:

On 20.07.22 13:04, Romain Manni-Bucau wrote:

 > There is no need to use toolchain to run your build with JDK17 and
 > create code for Java 8... you can use --release 8
 > (8)...
 >
 > No toolchain needed.

So you run tests with java 17? This is not what you want if your prod is
in java 8, you can still get surprises so you need toolchain in your
build (same happen for compilation since bytecode is not 1-1, only
signatures).


First what kind of surprises?

Second can you show an example of different bytes codes?


Just a regular Maven user here, but I'll give you an example, Karl 
Heinz, where testing against different Java versions was necessary to 
avoid shipping a blocker bug -- even though the bytecode didn't differ 
at all.


Some context: We maintain a couple of plug-ins for different IDEs 
(Eclipse, IntelliJ, NetBeans). Each plugin needs to be compatible with a 
whole range of IDE versions, as not all our users (can) use the latest 
and greatest. And different IDE versions usually mean different Java 
requirements, too.


In the case of the NetBeans plug-in (the same holds for Eclipse and 
IntelliJ, but these are build with Gradle and Maven+Tycho, respectively, 
rather than with plain Maven) this means that the plug-in needs to 
target Java 8 at the lower end, as older versions of NetBeans don't even 
run on the latest version of Java. Hence, we compile against Java 8.


However, we *also* occasionally test against newer versions of Java 
(e.g., in our nightly builds) to catch errors like the following:


The plug-in classloader of NetBeans [1] (and IntelliJ [2], FWIW) does 
not support multi-release JARs, which means that the following LOG4J2 
statement fails when running on Java 9 or later.


     private static final Logger LOGGER = LogManager.getLogger();

As the plug-in classloader does not support the multi-release 
capabilities of the Log4J2 JAR, we end up in the Java 8 variant of 
getLogger(), which no longer works under newer versions of Java. The 
resulting ExceptionInInitializerError completely breaks our plug-in, but 
this luckily has been found during testing -- running the tests with 
Java 9 or later.


I hope this example was useful to the discussion at hand.

Now, at the moment we run Maven itself with Java 17 (as it speeds up our 
builds) and use toolchains to compile *and* test against Java 8. During 
our nightly build, however, we also pass in a system property which 
selects a different toolchain (ATM, Java 11).


This works, but is not ideal, as our nightly sanity build not only tests 
against Java 11 but also builds against it; both maven-compiler-plugin 
and maven-surefire-plugin use the *same* toolchain. Unfortunately, this 
means that we don't have a guarantee that the test against Java 11 use 
the same bytecode that we ship, since the nightly build compiles with 
the Java 11 but we have to ship the code compiled against Java 8 (i.e., 
our lowest denominator).


In an ideal world, our setup would look like this:

- mvn: Runs with Java 17
- maven-compiler-plugin: --release 8
- maven-surefire-plugin: a Java 8/11/17 toolchain, selected by system
     property

At the moment, we are not there yet, as we cannot use --release, as 
there cannot be separate toolchains for compilation and test. If that 
were to change with Maven 4, that would be great, of course.


Hope this helps.


As I said. Such an example and a move to Java 17 would cause just 
friction without any lubricant.

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Andreas Sewe]

On 20.07.22 15:39, Karl Heinz Marbaise wrote:

On 20.07.22 13:04, Romain Manni-Bucau wrote:

 > There is no need to use toolchain to run your build with JDK17 and
 > create code for Java 8... you can use --release 8
 > (8)...
 >
 > No toolchain needed.

So you run tests with java 17? This is not what you want if your prod is
in java 8, you can still get surprises so you need toolchain in your
build (same happen for compilation since bytecode is not 1-1, only
signatures).


First what kind of surprises?

Second can you show an example of different bytes codes?


Just a regular Maven user here, but I'll give you an example, Karl 
Heinz, where testing against different Java versions was necessary to 
avoid shipping a blocker bug -- even though the bytecode didn't differ 
at all.


Some context: We maintain a couple of plug-ins for different IDEs 
(Eclipse, IntelliJ, NetBeans). Each plugin needs to be compatible with a 
whole range of IDE versions, as not all our users (can) use the latest 
and greatest. And different IDE versions usually mean different Java 
requirements, too.


In the case of the NetBeans plug-in (the same holds for Eclipse and 
IntelliJ, but these are build with Gradle and Maven+Tycho, respectively, 
rather than with plain Maven) this means that the plug-in needs to 
target Java 8 at the lower end, as older versions of NetBeans don't even 
run on the latest version of Java. Hence, we compile against Java 8.


However, we *also* occasionally test against newer versions of Java 
(e.g., in our nightly builds) to catch errors like the following:


The plug-in classloader of NetBeans [1] (and IntelliJ [2], FWIW) does 
not support multi-release JARs, which means that the following LOG4J2 
statement fails when running on Java 9 or later.


private static final Logger LOGGER = LogManager.getLogger();

As the plug-in classloader does not support the multi-release 
capabilities of the Log4J2 JAR, we end up in the Java 8 variant of 
getLogger(), which no longer works under newer versions of Java. The 
resulting ExceptionInInitializerError completely breaks our plug-in, but 
this luckily has been found during testing -- running the tests with 
Java 9 or later.


I hope this example was useful to the discussion at hand.

Now, at the moment we run Maven itself with Java 17 (as it speeds up our 
builds) and use toolchains to compile *and* test against Java 8. During 
our nightly build, however, we also pass in a system property which 
selects a different toolchain (ATM, Java 11).


This works, but is not ideal, as our nightly sanity build not only tests 
against Java 11 but also builds against it; both maven-compiler-plugin 
and maven-surefire-plugin use the *same* toolchain. Unfortunately, this 
means that we don't have a guarantee that the test against Java 11 use 
the same bytecode that we ship, since the nightly build compiles with 
the Java 11 but we have to ship the code compiled against Java 8 (i.e., 
our lowest denominator).


In an ideal world, our setup would look like this:

- mvn: Runs with Java 17
- maven-compiler-plugin: --release 8
- maven-surefire-plugin: a Java 8/11/17 toolchain, selected by system
property

At the moment, we are not there yet, as we cannot use --release, as 
there cannot be separate toolchains for compilation and test. If that 
were to change with Maven 4, that would be great, of course.


Hope this helps.

Best wishes,

Andreas Sewe

[1] 
[2] 

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Guillaume Nodet]

Le dim. 24 juil. 2022 à 08:54, Romain Manni-Bucau  a
écrit :

> Le sam. 23 juil. 2022 à 21:05, Enno Thieleke 
> a écrit :
>
> > Fwiw:
> >
> > Romain, I think you're exaggerating. The answer is, like in most cases:
> > "it depends".
> >
> > Most people, we're most likely talking 95-99% here, will happily use JDK
> > 17 with Maven 4.
> >
>
> I would lower the figure - keep in mind 95-99% of people also uses libs and
> are affected by what I described - but agree "most" would see it...at the
> cost of configuring toolchain and even just the test/compiler version in
> the pom which breaks our convention over config core design IMHO.
>
> So until we change our design to isolate all our core code and mojo run
> from contextual java version (most mojo are not toolchain friendly, this
> requires a mojo executor evolution to make the ecosystem functional), and
> likely means we can:
>
> 1. Have background jvm runners (reusable) to avoid the cold perf pitfall of
> toolchain
>

Aren't you just describing mvnd ?  mvnd is compiled to native already.


> 2. Toolchain functional for all mojo without any mojo change
> 3. A global property to limit the configuration for all mojo
>
> I dont think it would work well in practise.
>
> I also dont want to exclude 50% of users (8+11) just cause we think we
> would maybe gain from that - there is very few valid reason in terms of
> compilation to do that on our side.
>
> Side note: technically, if reached, it means we can make mvn a native
> binary with graalvm and run mojo in java runner so java wouldnt be a real
> constraint for us/users but this has high impacts in terms of design and
> code update requirements.
>
>
> > Some people might need to compile for lower sources and targets, but
> > running tests for those builds in JDK 17 instead of, let's say 11, _will
> > suffice in most cases_.
> >
> > Yes, there will be edge cases where people will be forced to use
> different
> > JDKs at least for tests, some even for builds. But that's possible, so
> they
> > won't get left behind.
> >
> > Regarding mvnd: It's not a silver bullet. It never was and it never will
> > be. Whenever a build spawns new JVMs (for tests or other tasks), it
> doesn't
> > benefit from mvnd anymore (in as much as it would without spawning new
> > JVMs).
> >
> > To not use the latest (LTS) JDK in order to "better" support the 1-5% of
> > the Maven users, who're still using obsolete JVMs (I'm obviously
> referring
> > to Karl's assumption, which I agree with), would be a kick in the teeth
> of
> > all Maven developers, who finally want to embrace the present (not even
> the
> > future).
> >
> > Long story short, +1 for JDK 17 as minimum for Maven 4.
> >
> > Kind regards,
> > Enno
> >
> > 
> > From: Romain Manni-Bucau 
> > Sent: Saturday, July 23, 2022 6:55 PM
> > To: Maven Developers List 
> > Subject: Re: Question - JDK Minimum of future Apache Maven 4.0.0
> >
> > Le sam. 23 juil. 2022 à 17:25, Benjamin Marwell  a
> > écrit :
> >
> > > No, 2 JDKs are not required by default. Only if you use --release={<17}
> > and
> > > don't trust running tests on 17 are the same as running tests on 8.
> > > Yes, there are changes (certificates, XML libs, rhino, etc).
> > >
> >
> > As explained it means you dont write a single test or dont care of the
> test
> > results so yes it needs 2 jdk.
> >
> >
> >
> > > So, for most projects that's probably not needed. For those who think
> it
> > is
> > > needed, I don't have a lot of pity. But it will be a requirement for
> > quite
> > > a few commercial projects, like Containers (JavaEE, as they will need
> to
> > be
> > > Java 8 as long as 2030ish due to extended support contracts).
> > >
> > > That said, I'm still thinking Java 17 will be a sane default.
> > >
> > >
> > > On Sat, 23 Jul 2022, 10:50 Delany,  wrote:
> > >
> > > > Using mvnd with toolchains doesn't improve the situation, in fact
> > > > toolchains seem to invalidate any benefit of using mvnd.
> > > > Even if this was resolved, is it fair to require mvnd?
> > > > Delany
> > > >
> > > >
> > > > On Sat, 23 Jul 2022 at 10:17, Mark Derricutt 
> wrote:
> > > >
> > > > >  Is that due to cold starting the JVM each time?
> > > > >
> > > > > I wonder if mvnd supports toolchains effectively?  Or if that could
> > be
> > > an
> > > > > avenue to try.
> > > > > --
> > > > > "Great artists are extremely selfish and arrogant things" — Steven
> > > > Wilson,
> > > > > Porcupine Tree
> > > > >
> > > > > On 23/07/2022 at 8:13:23 PM, Delany 
> > > wrote:
> > > > >
> > > > > > I tried toolchains but dropped it because of the exorbitant
> > > performance
> > > > > > costs.
> > > > > > A multi-module build that normally built in 3:50 took 10:34, and
> > > that's
> > > > > > with toolchaining only maven-compiler-plugin.
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>


-- 

Guillaume Nodet

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Michael Osipov]

Am 2022-07-24 um 13:00 schrieb Maarten Mulders:

Hi all,

Allow me to chime in on this long-running discussion... I haven't raised 
my voice yet, as I was curious for other opinions.


*My vote would be Java 17 for both building and running Maven 4.*

I certainly agree with the points brought up by Karl-Heinz and Benjamin 
regarding Toolchains. If you really need it, you can use it. I would say 
we shouldn't advise our users to use Toolchains by default; many code 
bases will probably not need it. Think about all those in-house 
developed applications alone, where the team knows perfectly well which 
version of which JVM they will be using in production.


I would like to bring an additional point to the table. I think we all 
agree we could use more people to contribute to Maven, preferably even 
on a frequent basis. I have already seen multiple people getting scared 
(and demotivated) by the fact that we have a huge code base which is 
written with Java 7 and more recently Java 8. This means people can't 
use language features that more recent versions of Java introduced, and 
get discouraged by having to write code in what they experience as 
"ancient" or even "pre-historic" versions of Java.


Attracting new contributors is not my main reason for voting Java 17 in 
Maven 4, but it certainly plays a role for me.


While I understand these points, I don't believe that Java 17 will buy 
us something substantial. We have much bigger problems than adding new 
features and Java dependencies. Look into Jira, we have almost 2000 open 
issues (50% are bugs), many of the years old. We have 5+ years of 
technical dept components not touched, not reviewed (Tamás and me are 
doing *a lot* of cleanup last couple of months). We have components 
maintained by a single person for years although they are vital for the 
entire ecosystem. I consider the entire discussion counterproductive. 
There are maybe hipsters which would like to use records in Java code in 
Maven core, but that won't solve any substantial problems except for 
fanciness. At the end such moves will lead to cannibalism in the community.


M

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Maven Site Plugin version 4.0.0-M3

[Michael Osipov]

Guys,

please take a moment to review...




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Maarten Mulders]

Hi all,

Allow me to chime in on this long-running discussion... I haven't raised 
my voice yet, as I was curious for other opinions.


*My vote would be Java 17 for both building and running Maven 4.*

I certainly agree with the points brought up by Karl-Heinz and Benjamin 
regarding Toolchains. If you really need it, you can use it. I would say 
we shouldn't advise our users to use Toolchains by default; many code 
bases will probably not need it. Think about all those in-house 
developed applications alone, where the team knows perfectly well which 
version of which JVM they will be using in production.


I would like to bring an additional point to the table. I think we all 
agree we could use more people to contribute to Maven, preferably even 
on a frequent basis. I have already seen multiple people getting scared 
(and demotivated) by the fact that we have a huge code base which is 
written with Java 7 and more recently Java 8. This means people can't 
use language features that more recent versions of Java introduced, and 
get discouraged by having to write code in what they experience as 
"ancient" or even "pre-historic" versions of Java.


Attracting new contributors is not my main reason for voting Java 17 in 
Maven 4, but it certainly plays a role for me.



Thanks,

Maarten

On 24/07/2022 08:54, Romain Manni-Bucau wrote:

Le sam. 23 juil. 2022 à 21:05, Enno Thieleke 
a écrit :


Fwiw:

Romain, I think you're exaggerating. The answer is, like in most cases:
"it depends".

Most people, we're most likely talking 95-99% here, will happily use JDK
17 with Maven 4.



I would lower the figure - keep in mind 95-99% of people also uses libs and
are affected by what I described - but agree "most" would see it...at the
cost of configuring toolchain and even just the test/compiler version in
the pom which breaks our convention over config core design IMHO.

So until we change our design to isolate all our core code and mojo run
from contextual java version (most mojo are not toolchain friendly, this
requires a mojo executor evolution to make the ecosystem functional), and
likely means we can:

1. Have background jvm runners (reusable) to avoid the cold perf pitfall of
toolchain
2. Toolchain functional for all mojo without any mojo change
3. A global property to limit the configuration for all mojo

I dont think it would work well in practise.

I also dont want to exclude 50% of users (8+11) just cause we think we
would maybe gain from that - there is very few valid reason in terms of
compilation to do that on our side.

Side note: technically, if reached, it means we can make mvn a native
binary with graalvm and run mojo in java runner so java wouldnt be a real
constraint for us/users but this has high impacts in terms of design and
code update requirements.



Some people might need to compile for lower sources and targets, but
running tests for those builds in JDK 17 instead of, let's say 11, _will
suffice in most cases_.

Yes, there will be edge cases where people will be forced to use different
JDKs at least for tests, some even for builds. But that's possible, so they
won't get left behind.

Regarding mvnd: It's not a silver bullet. It never was and it never will
be. Whenever a build spawns new JVMs (for tests or other tasks), it doesn't
benefit from mvnd anymore (in as much as it would without spawning new
JVMs).

To not use the latest (LTS) JDK in order to "better" support the 1-5% of
the Maven users, who're still using obsolete JVMs (I'm obviously referring
to Karl's assumption, which I agree with), would be a kick in the teeth of
all Maven developers, who finally want to embrace the present (not even the
future).

Long story short, +1 for JDK 17 as minimum for Maven 4.

Kind regards,
Enno


From: Romain Manni-Bucau 
Sent: Saturday, July 23, 2022 6:55 PM
To: Maven Developers List 
Subject: Re: Question - JDK Minimum of future Apache Maven 4.0.0

Le sam. 23 juil. 2022 à 17:25, Benjamin Marwell  a
écrit :


No, 2 JDKs are not required by default. Only if you use --release={<17}

and

don't trust running tests on 17 are the same as running tests on 8.
Yes, there are changes (certificates, XML libs, rhino, etc).



As explained it means you dont write a single test or dont care of the test
results so yes it needs 2 jdk.




So, for most projects that's probably not needed. For those who think it

is

needed, I don't have a lot of pity. But it will be a requirement for

quite

a few commercial projects, like Containers (JavaEE, as they will need to

be

Java 8 as long as 2030ish due to extended support contracts).

That said, I'm still thinking Java 17 will be a sane default.


On Sat, 23 Jul 2022, 10:50 Delany,  wrote:


Using mvnd with toolchains doesn't improve the situation, in fact
toolchains seem to invalidate any benefit of using mvnd.
Even if this was resolved, is it fair to require mvnd?
Delany


On Sat, 23 Jul 2022 at 10:17, Mark Derricutt  wrote:


  Is 

Re: Question - JDK Minimum of future Apache Maven 4.0.0

[Romain Manni-Bucau]

Le sam. 23 juil. 2022 à 21:05, Enno Thieleke 
a écrit :

> Fwiw:
>
> Romain, I think you're exaggerating. The answer is, like in most cases:
> "it depends".
>
> Most people, we're most likely talking 95-99% here, will happily use JDK
> 17 with Maven 4.
>

I would lower the figure - keep in mind 95-99% of people also uses libs and
are affected by what I described - but agree "most" would see it...at the
cost of configuring toolchain and even just the test/compiler version in
the pom which breaks our convention over config core design IMHO.

So until we change our design to isolate all our core code and mojo run
from contextual java version (most mojo are not toolchain friendly, this
requires a mojo executor evolution to make the ecosystem functional), and
likely means we can:

1. Have background jvm runners (reusable) to avoid the cold perf pitfall of
toolchain
2. Toolchain functional for all mojo without any mojo change
3. A global property to limit the configuration for all mojo

I dont think it would work well in practise.

I also dont want to exclude 50% of users (8+11) just cause we think we
would maybe gain from that - there is very few valid reason in terms of
compilation to do that on our side.

Side note: technically, if reached, it means we can make mvn a native
binary with graalvm and run mojo in java runner so java wouldnt be a real
constraint for us/users but this has high impacts in terms of design and
code update requirements.


> Some people might need to compile for lower sources and targets, but
> running tests for those builds in JDK 17 instead of, let's say 11, _will
> suffice in most cases_.
>
> Yes, there will be edge cases where people will be forced to use different
> JDKs at least for tests, some even for builds. But that's possible, so they
> won't get left behind.
>
> Regarding mvnd: It's not a silver bullet. It never was and it never will
> be. Whenever a build spawns new JVMs (for tests or other tasks), it doesn't
> benefit from mvnd anymore (in as much as it would without spawning new
> JVMs).
>
> To not use the latest (LTS) JDK in order to "better" support the 1-5% of
> the Maven users, who're still using obsolete JVMs (I'm obviously referring
> to Karl's assumption, which I agree with), would be a kick in the teeth of
> all Maven developers, who finally want to embrace the present (not even the
> future).
>
> Long story short, +1 for JDK 17 as minimum for Maven 4.
>
> Kind regards,
> Enno
>
> 
> From: Romain Manni-Bucau 
> Sent: Saturday, July 23, 2022 6:55 PM
> To: Maven Developers List 
> Subject: Re: Question - JDK Minimum of future Apache Maven 4.0.0
>
> Le sam. 23 juil. 2022 à 17:25, Benjamin Marwell  a
> écrit :
>
> > No, 2 JDKs are not required by default. Only if you use --release={<17}
> and
> > don't trust running tests on 17 are the same as running tests on 8.
> > Yes, there are changes (certificates, XML libs, rhino, etc).
> >
>
> As explained it means you dont write a single test or dont care of the test
> results so yes it needs 2 jdk.
>
>
>
> > So, for most projects that's probably not needed. For those who think it
> is
> > needed, I don't have a lot of pity. But it will be a requirement for
> quite
> > a few commercial projects, like Containers (JavaEE, as they will need to
> be
> > Java 8 as long as 2030ish due to extended support contracts).
> >
> > That said, I'm still thinking Java 17 will be a sane default.
> >
> >
> > On Sat, 23 Jul 2022, 10:50 Delany,  wrote:
> >
> > > Using mvnd with toolchains doesn't improve the situation, in fact
> > > toolchains seem to invalidate any benefit of using mvnd.
> > > Even if this was resolved, is it fair to require mvnd?
> > > Delany
> > >
> > >
> > > On Sat, 23 Jul 2022 at 10:17, Mark Derricutt  wrote:
> > >
> > > >  Is that due to cold starting the JVM each time?
> > > >
> > > > I wonder if mvnd supports toolchains effectively?  Or if that could
> be
> > an
> > > > avenue to try.
> > > > --
> > > > "Great artists are extremely selfish and arrogant things" — Steven
> > > Wilson,
> > > > Porcupine Tree
> > > >
> > > > On 23/07/2022 at 8:13:23 PM, Delany 
> > wrote:
> > > >
> > > > > I tried toolchains but dropped it because of the exorbitant
> > performance
> > > > > costs.
> > > > > A multi-module build that normally built in 3:50 took 10:34, and
> > that's
> > > > > with toolchaining only maven-compiler-plugin.
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>