Le dim. 24 juil. 2022 à 20:56, Guillaume Nodet <gno...@apache.org> a écrit :
> Le dim. 24 juil. 2022 à 08:54, Romain Manni-Bucau <rmannibu...@gmail.com>
> 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 <rmannibu...@gmail.com>
> > > Sent: Saturday, July 23, 2022 6:55 PM
> > > To: Maven Developers List <dev@maven.apache.org>
> > > Subject: Re: Question - JDK Minimum of future Apache Maven 4.0.0
> > >
> > > Le sam. 23 juil. 2022 à 17:25, Benjamin Marwell <bmarw...@apache.org>
> 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, <delany.middle...@gmail.com>
> 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 <m...@talios.com>
> > 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 <delany.middle...@gmail.com>
> > > > 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
>
