You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Matthias Bünger <mb...@apache.org> on 2025/05/04 06:57:04 UTC
[RESULT][VOTE] Require Java 21 for Maven 4 (Rephrased Vote)
Morning everyone,
first I would like to thank everybody who participated in the vote [*1]
about lifting the required Java version to 21 for Maven 4.0.0.
The vote has ended with the following votes:
--------------
Binding votes:
+1: Sylwester Lachiewicz, Karl Heinz Marbaise, Tamás Cservenák, Benjamin
Marwell, Arnaud Héritier, Tibor Digaňa
-1: Michael Osipov, Maarten Mulders, Olivier Lamy, Slawomir Jaranowski,
Hervé Boutemy
Non-binding votes:
+1: Gary Gregory, Mateusz Gajewski, Mantas Gridinas, Rodrigo Bourbon,
Willker Gomes, Hans Aikema, Martin Desruisseaux, Torsten Heit, Sandra
Parsick, Dawid Law, Philipp Picej, John Neffenger, Jeremy Landis, Daniel
B. Widdis, Michael Bien, Gregorz Grzybek, Kévin Buntrock, Jorge
Solorzano, Mark Derricutt, Matthias Bünger, Basil Crow, Romain
Manni-Bucau, Thomas Sundberg, Anders Hammar, Piotr P. Karwasz, Niels
Basjes, Enrico Olivelli
-1: Elliotte Rusty Harold
--------------
5 out of 11 binding votes are -1 with valid arguments, including that
there is no actual need to upgrade, that (it's too late, as ) we are
already in RC phase, and that it might put on new constraints to users.
The vote was (in line to the vote about lifting Maven 4 to Java 17) a
"procedural majority vote", meaing a simple majority of binding votes
would be enough to considered it to be passed. But due the high number
of negative votes and brought up arguments, I don't think we should
ignore them but take them into consideration for the benefit of the
Maven community. Therefore I call the vote to be non successful. We can
reevaluate in the future, including having a closer look at / discussion
about the benefits and constraints of raising the Java version.
Wish you a happy sunday!
Matthias
[*1]: https://lists.apache.org/thread/mjbx64vlbd346ov3l4wj6fy9vh8608vr
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [RESULT][VOTE] Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Delany <de...@gmail.com>.
I was also thinking the ability of a community to vote and move forward
with whatever the result
is more important than the result itself. Disputing *this* vote slows
getting to the next one.
Its not even the kind of vote that would change the direction of the
project.
Delany
On Fri, 23 May 2025 at 22:06, Gary Gregory <ga...@gmail.com> wrote:
> There is an interesting parallel here with the what is happening in the
> logo-dev mailing list: Someone calls for a vote, the results are obvious
> (count the votes), then it feels like we are back to square one when some
> starts haggling the whole thing over again. This might not be a bad thing,
> we are not machines or anywhere near perfect but I just found it
> interesting.
>
> Gary
>
> On Fri, May 23, 2025, 15:34 Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > I do not think we can use that as a point otherwise we should go with
> java
> > 8.
> > So question is really do we go with what is current when we do the final
> or
> > do we go with a past choice assuming people not upgrading their stack
> will
> > upgrade their stack cause maven 4 is too awesome to not upgrade.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://x.com/rmannibucau> | .NET Blog
> > <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/
> >
> > | Old
> > Blog <http://rmannibucau.wordpress.com> | Github
> > <https://github.com/rmannibucau> | LinkedIn
> > <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> >
> https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064
> > >
> >
> >
> > Le ven. 23 mai 2025 à 21:05, Gary Gregory <ga...@gmail.com> a
> > écrit :
> >
> > > On Fri, May 23, 2025, 13:40 Benjamin Marwell <bm...@apache.org>
> > wrote:
> > >
> > > > Hey, I can totally understand the people voting -1 for the given
> > reasons.
> > > > Even with Java 17 support ending in ~15 months FOR PERSONAL USE.
> > > > There will be a loooooong tail of extended support for money.
> > > >
> > >
> > >
> > > And how much of this moooooooney will come to Maven maintainers?
> > >
> > > Gary
> > >
> > >
> > > > Anyway, my suggestion:
> > > > Let's do Maven 4.0.0 with Java 17.
> > > > Wait for a 4.0.1, 4.1.0... and then with Maven 4.2.0 or 4.3.0 let's
> > > > look again into lifting the runtime requirement to Java 21.
> > > > By then, community support is about to end and most plugins will be
> > > > lifted to 17, which will give us a much tighter ecosystem.
> > > >
> > > > "Aufgeschoben ist nicht aufgehoben" => "Postponed is not cancelled"
> > > >
> > > > Does that work for you? Sounds like a reasonable common ground.
> > > > It is similar to what has been done with Maven 3, no?
> > > >
> > > > - Ben
> > > >
> > > > Am Mo., 12. Mai 2025 um 23:42 Uhr schrieb Henning Schmiedehausen
> > > > <he...@schmiedehausen.org.invalid>:
> > > > >
> > > > > As a case in point, I am slowly moving the plugins that I maintain
> (
> > > > > https://basepom.github.io/) to Java 17 and 21, even though these
> are
> > > > Maven
> > > > > 3.x.x plugins. I will require projects that adopt those to use 17
> or
> > 21
> > > > to
> > > > > run the build. Which is fine, because I can still deliver Java 8 or
> > > Java
> > > > 11
> > > > > compatible software even if building on a newer JDK.
> > > > >
> > > > > Java 17 is "end of public support" in ~ 15 months. By that time,
> two
> > > > newer
> > > > > LTS versions (21 and 25) will be available. And 21 gives a path to
> > use
> > > > > things like FFI which do not exist in 17.
> > > > >
> > > > > This decision seems to be too much on the conservative side. Anyone
> > who
> > > > > does not want to upgrade Java will not upgrade to Maven 4 anyway.
> > > > >
> > > > > -h
> > > > >
> > > > >
> > > > >
> > > > > On Sat, May 10, 2025 at 1:17 PM Tamás Cservenák <
> tamas@cservenak.net
> > >
> > > > wrote:
> > > > >
> > > > > > Howdy,
> > > > > >
> > > > > > very same sentiment over here as well. I am very disappointed
> with
> > > the
> > > > > > outcome.
> > > > > >
> > > > > > So, I am curious about folks voting -1...
> > > > > >
> > > > > > Is one of them planning to go rogue and surprise us all by doing
> a
> > > > > > Maven 4 GA release soon? :D
> > > > > >
> > > > > > Thanks
> > > > > >
> > > > > > T
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Sat, May 10, 2025 at 8:58 PM Mirko Friedenhagen
> > > > > > <mf...@gmx.de.invalid> wrote:
> > > > > > >
> > > > > > > I completely second Manfred here:
> > > > > > >
> > > > > > > - People who are willing to use Maven 4 soonish should be
> > > considered
> > > > > > fast movers. So I guess these are already using Java 21 anyways.
> > > > > > > - Going from Java 17 to 21 does not require major adaptions if
> > any
> > > in
> > > > > > code in my experience.
> > > > > > > - New LTS Java 25 comes out this year, so even 21 will not be
> the
> > > > shiny
> > > > > > new version.
> > > > > > >
> > > > > > > Mit freundlichen Grüßen
> > > > > > > Mirko Friedenhagen
> > > > > > > —
> > > > > > > Sent from my mobile
> > > > > > >
> > > > > > > > Am 04.05.2025 um 20:45 schrieb Manfred Moser <
> > > > manfred@simpligility.ca
> > > > > > >:
> > > > > > > >
> > > > > > > > Hi all,
> > > > > > > >
> > > > > > > > I find this extremely disappointing and also confusing. A
> > > majority
> > > > of
> > > > > > binding and non-binding votes opted FOR adopting Java 21. How can
> > > this
> > > > be
> > > > > > justified with our procedures?
> > > > > > > >
> > > > > > > > Here are my arguments for adopting Java 21 that seems to have
> > > been
> > > > > > asked for although they are imho obvious.
> > > > > > > >
> > > > > > > > * Maven 4 will be a brand new release with many changes. An
> > > > upgrade of
> > > > > > the required Java version is already included. Changing that from
> > 17
> > > > to 21
> > > > > > does not have that much impact on users.
> > > > > > > >
> > > > > > > > * Java 21 is the latest current Java LTS release, and Java 25
> > as
> > > > the
> > > > > > next LTS will be out in September .. that might even be before
> > Maven
> > > 4
> > > > > > ships.
> > > > > > > >
> > > > > > > > * Java 21 has numerous improvements on top of 17 that making
> > > > > > programming with it better (and newer versions are even better).
> > > > > > > >
> > > > > > > > * Programmers will be less inclined to help a project that
> uses
> > > an
> > > > old
> > > > > > Java version (17 is 3 years old.. ) and therefore prohibits them
> > for
> > > > using
> > > > > > modern programming styles and usage.
> > > > > > > >
> > > > > > > > * Performance of Java 21 is better and it is more suitable to
> > run
> > > > on
> > > > > > containers (which is common for CI and CD systems these days.
> > > > > > > >
> > > > > > > > * As a project overall we should strive to provide modern
> > > powerful
> > > > > > tooling and that also includes using modern runtime versions and
> > > taking
> > > > > > advantage of new features.
> > > > > > > >
> > > > > > > > * A later upgrade to Java 21 in in 4.1 for example seem to
> make
> > > > sense
> > > > > > sense for a minor version update.
> > > > > > > >
> > > > > > > > * Holding us back to Java 17 means we can not start
> refactoring
> > > the
> > > > > > code to take advantage of features from 18, 19, 20, and 21.
> > > > > > > >
> > > > > > > > Beyond that I want to discount the "valid" arguments:
> > > > > > > >
> > > > > > > > * Procedurally there is nothing wrong with changing in the RC
> > > > phase.
> > > > > > There is no rule about how long that phase is and how many RCs
> > there
> > > > should
> > > > > > be.
> > > > > > > >
> > > > > > > > * The new constraints on users only apply if they upgrade to
> > > Maven
> > > > 4
> > > > > > .. which is completely optional.
> > > > > > > >
> > > > > > > > * Even people who voted with -1 said that they would like to
> > > > upgrade
> > > > > > and that it would be nice, so what is really holding this back.
> > > > > > > >
> > > > > > > > I therefore ask for the conclusion to be reconsidered and
> > > following
> > > > > > our majority rules to adopt the raise to Java 21 as requirements
> > for
> > > > Maven
> > > > > > 4 before we release a final version.
> > > > > > > >
> > > > > > > > Manfred
> > > > > > > >
> > > > > > > >> On 2025-05-03 11:57 p.m., Matthias Bünger wrote:
> > > > > > > >> Morning everyone,
> > > > > > > >> first I would like to thank everybody who participated in
> the
> > > vote
> > > > > > [*1] about lifting the required Java version to 21 for Maven
> 4.0.0.
> > > > > > > >>
> > > > > > > >> The vote has ended with the following votes:
> > > > > > > >>
> > > > > > > >> --------------
> > > > > > > >> Binding votes:
> > > > > > > >>
> > > > > > > >> +1: Sylwester Lachiewicz, Karl Heinz Marbaise, Tamás
> > Cservenák,
> > > > > > Benjamin Marwell, Arnaud Héritier, Tibor Digaňa
> > > > > > > >>
> > > > > > > >> -1: Michael Osipov, Maarten Mulders, Olivier Lamy, Slawomir
> > > > > > Jaranowski, Hervé Boutemy
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> Non-binding votes:
> > > > > > > >>
> > > > > > > >> +1: Gary Gregory, Mateusz Gajewski, Mantas Gridinas, Rodrigo
> > > > Bourbon,
> > > > > > Willker Gomes, Hans Aikema, Martin Desruisseaux, Torsten Heit,
> > Sandra
> > > > > > Parsick, Dawid Law, Philipp Picej, John Neffenger, Jeremy Landis,
> > > > Daniel B.
> > > > > > Widdis, Michael Bien, Gregorz Grzybek, Kévin Buntrock, Jorge
> > > Solorzano,
> > > > > > Mark Derricutt, Matthias Bünger, Basil Crow, Romain Manni-Bucau,
> > > Thomas
> > > > > > Sundberg, Anders Hammar, Piotr P. Karwasz, Niels Basjes, Enrico
> > > > Olivelli
> > > > > > > >>
> > > > > > > >> -1: Elliotte Rusty Harold
> > > > > > > >>
> > > > > > > >> --------------
> > > > > > > >>
> > > > > > > >> 5 out of 11 binding votes are -1 with valid arguments,
> > including
> > > > that
> > > > > > there is no actual need to upgrade, that (it's too late, as ) we
> > are
> > > > > > already in RC phase, and that it might put on new constraints to
> > > > users. The
> > > > > > vote was (in line to the vote about lifting Maven 4 to Java 17) a
> > > > > > "procedural majority vote", meaing a simple majority of binding
> > votes
> > > > would
> > > > > > be enough to considered it to be passed. But due the high number
> of
> > > > > > negative votes and brought up arguments, I don't think we should
> > > ignore
> > > > > > them but take them into consideration for the benefit of the
> Maven
> > > > > > community. Therefore I call the vote to be non successful. We can
> > > > > > reevaluate in the future, including having a closer look at /
> > > > discussion
> > > > > > about the benefits and constraints of raising the Java version.
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> Wish you a happy sunday!
> > > > > > > >> Matthias
> > > > > > > >>
> > > > > > > >> [*1]:
> > > > > > https://lists.apache.org/thread/mjbx64vlbd346ov3l4wj6fy9vh8608vr
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > ---------------------------------------------------------------------
> > > > > > > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > >> For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > >
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >
> > > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
>
Re: [RESULT][VOTE] Require Java 21 for Maven 4 (Rephrased Vote)
Posted by David Jencks <da...@gmail.com>.
I’m confused by what you wrote, and not going to spend my time looking for parallels on logo-dev. IIUC the vote was clearly for moving to java 21, but due to some reasoning in the -1 votes this was rejected: since then a bunch of people have objected to failing the vote. Specifically, which results are obvious, and are the pro or anti java 21 folks starting the haggling?
thanks
David Jencks
> On May 23, 2025, at 1:05 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> There is an interesting parallel here with the what is happening in the
> logo-dev mailing list: Someone calls for a vote, the results are obvious
> (count the votes), then it feels like we are back to square one when some
> starts haggling the whole thing over again. This might not be a bad thing,
> we are not machines or anywhere near perfect but I just found it
> interesting.
>
> Gary
>
> On Fri, May 23, 2025, 15:34 Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>> I do not think we can use that as a point otherwise we should go with java
>> 8.
>> So question is really do we go with what is current when we do the final or
>> do we go with a past choice assuming people not upgrading their stack will
>> upgrade their stack cause maven 4 is too awesome to not upgrade.
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://x.com/rmannibucau> | .NET Blog
>> <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/>
>> | Old
>> Blog <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Book
>> <
>> https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064
>>>
>>
>>
>> Le ven. 23 mai 2025 à 21:05, Gary Gregory <ga...@gmail.com> a
>> écrit :
>>
>>> On Fri, May 23, 2025, 13:40 Benjamin Marwell <bm...@apache.org>
>> wrote:
>>>
>>>> Hey, I can totally understand the people voting -1 for the given
>> reasons.
>>>> Even with Java 17 support ending in ~15 months FOR PERSONAL USE.
>>>> There will be a loooooong tail of extended support for money.
>>>>
>>>
>>>
>>> And how much of this moooooooney will come to Maven maintainers?
>>>
>>> Gary
>>>
>>>
>>>> Anyway, my suggestion:
>>>> Let's do Maven 4.0.0 with Java 17.
>>>> Wait for a 4.0.1, 4.1.0... and then with Maven 4.2.0 or 4.3.0 let's
>>>> look again into lifting the runtime requirement to Java 21.
>>>> By then, community support is about to end and most plugins will be
>>>> lifted to 17, which will give us a much tighter ecosystem.
>>>>
>>>> "Aufgeschoben ist nicht aufgehoben" => "Postponed is not cancelled"
>>>>
>>>> Does that work for you? Sounds like a reasonable common ground.
>>>> It is similar to what has been done with Maven 3, no?
>>>>
>>>> - Ben
>>>>
>>>> Am Mo., 12. Mai 2025 um 23:42 Uhr schrieb Henning Schmiedehausen
>>>> <he...@schmiedehausen.org.invalid>:
>>>>>
>>>>> As a case in point, I am slowly moving the plugins that I maintain (
>>>>> https://basepom.github.io/) to Java 17 and 21, even though these are
>>>> Maven
>>>>> 3.x.x plugins. I will require projects that adopt those to use 17 or
>> 21
>>>> to
>>>>> run the build. Which is fine, because I can still deliver Java 8 or
>>> Java
>>>> 11
>>>>> compatible software even if building on a newer JDK.
>>>>>
>>>>> Java 17 is "end of public support" in ~ 15 months. By that time, two
>>>> newer
>>>>> LTS versions (21 and 25) will be available. And 21 gives a path to
>> use
>>>>> things like FFI which do not exist in 17.
>>>>>
>>>>> This decision seems to be too much on the conservative side. Anyone
>> who
>>>>> does not want to upgrade Java will not upgrade to Maven 4 anyway.
>>>>>
>>>>> -h
>>>>>
>>>>>
>>>>>
>>>>> On Sat, May 10, 2025 at 1:17 PM Tamás Cservenák <tamas@cservenak.net
>>>
>>>> wrote:
>>>>>
>>>>>> Howdy,
>>>>>>
>>>>>> very same sentiment over here as well. I am very disappointed with
>>> the
>>>>>> outcome.
>>>>>>
>>>>>> So, I am curious about folks voting -1...
>>>>>>
>>>>>> Is one of them planning to go rogue and surprise us all by doing a
>>>>>> Maven 4 GA release soon? :D
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> T
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, May 10, 2025 at 8:58 PM Mirko Friedenhagen
>>>>>> <mf...@gmx.de.invalid> wrote:
>>>>>>>
>>>>>>> I completely second Manfred here:
>>>>>>>
>>>>>>> - People who are willing to use Maven 4 soonish should be
>>> considered
>>>>>> fast movers. So I guess these are already using Java 21 anyways.
>>>>>>> - Going from Java 17 to 21 does not require major adaptions if
>> any
>>> in
>>>>>> code in my experience.
>>>>>>> - New LTS Java 25 comes out this year, so even 21 will not be the
>>>> shiny
>>>>>> new version.
>>>>>>>
>>>>>>> Mit freundlichen Grüßen
>>>>>>> Mirko Friedenhagen
>>>>>>> —
>>>>>>> Sent from my mobile
>>>>>>>
>>>>>>>> Am 04.05.2025 um 20:45 schrieb Manfred Moser <
>>>> manfred@simpligility.ca
>>>>>>> :
>>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I find this extremely disappointing and also confusing. A
>>> majority
>>>> of
>>>>>> binding and non-binding votes opted FOR adopting Java 21. How can
>>> this
>>>> be
>>>>>> justified with our procedures?
>>>>>>>>
>>>>>>>> Here are my arguments for adopting Java 21 that seems to have
>>> been
>>>>>> asked for although they are imho obvious.
>>>>>>>>
>>>>>>>> * Maven 4 will be a brand new release with many changes. An
>>>> upgrade of
>>>>>> the required Java version is already included. Changing that from
>> 17
>>>> to 21
>>>>>> does not have that much impact on users.
>>>>>>>>
>>>>>>>> * Java 21 is the latest current Java LTS release, and Java 25
>> as
>>>> the
>>>>>> next LTS will be out in September .. that might even be before
>> Maven
>>> 4
>>>>>> ships.
>>>>>>>>
>>>>>>>> * Java 21 has numerous improvements on top of 17 that making
>>>>>> programming with it better (and newer versions are even better).
>>>>>>>>
>>>>>>>> * Programmers will be less inclined to help a project that uses
>>> an
>>>> old
>>>>>> Java version (17 is 3 years old.. ) and therefore prohibits them
>> for
>>>> using
>>>>>> modern programming styles and usage.
>>>>>>>>
>>>>>>>> * Performance of Java 21 is better and it is more suitable to
>> run
>>>> on
>>>>>> containers (which is common for CI and CD systems these days.
>>>>>>>>
>>>>>>>> * As a project overall we should strive to provide modern
>>> powerful
>>>>>> tooling and that also includes using modern runtime versions and
>>> taking
>>>>>> advantage of new features.
>>>>>>>>
>>>>>>>> * A later upgrade to Java 21 in in 4.1 for example seem to make
>>>> sense
>>>>>> sense for a minor version update.
>>>>>>>>
>>>>>>>> * Holding us back to Java 17 means we can not start refactoring
>>> the
>>>>>> code to take advantage of features from 18, 19, 20, and 21.
>>>>>>>>
>>>>>>>> Beyond that I want to discount the "valid" arguments:
>>>>>>>>
>>>>>>>> * Procedurally there is nothing wrong with changing in the RC
>>>> phase.
>>>>>> There is no rule about how long that phase is and how many RCs
>> there
>>>> should
>>>>>> be.
>>>>>>>>
>>>>>>>> * The new constraints on users only apply if they upgrade to
>>> Maven
>>>> 4
>>>>>> .. which is completely optional.
>>>>>>>>
>>>>>>>> * Even people who voted with -1 said that they would like to
>>>> upgrade
>>>>>> and that it would be nice, so what is really holding this back.
>>>>>>>>
>>>>>>>> I therefore ask for the conclusion to be reconsidered and
>>> following
>>>>>> our majority rules to adopt the raise to Java 21 as requirements
>> for
>>>> Maven
>>>>>> 4 before we release a final version.
>>>>>>>>
>>>>>>>> Manfred
>>>>>>>>
>>>>>>>>> On 2025-05-03 11:57 p.m., Matthias Bünger wrote:
>>>>>>>>> Morning everyone,
>>>>>>>>> first I would like to thank everybody who participated in the
>>> vote
>>>>>> [*1] about lifting the required Java version to 21 for Maven 4.0.0.
>>>>>>>>>
>>>>>>>>> The vote has ended with the following votes:
>>>>>>>>>
>>>>>>>>> --------------
>>>>>>>>> Binding votes:
>>>>>>>>>
>>>>>>>>> +1: Sylwester Lachiewicz, Karl Heinz Marbaise, Tamás
>> Cservenák,
>>>>>> Benjamin Marwell, Arnaud Héritier, Tibor Digaňa
>>>>>>>>>
>>>>>>>>> -1: Michael Osipov, Maarten Mulders, Olivier Lamy, Slawomir
>>>>>> Jaranowski, Hervé Boutemy
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Non-binding votes:
>>>>>>>>>
>>>>>>>>> +1: Gary Gregory, Mateusz Gajewski, Mantas Gridinas, Rodrigo
>>>> Bourbon,
>>>>>> Willker Gomes, Hans Aikema, Martin Desruisseaux, Torsten Heit,
>> Sandra
>>>>>> Parsick, Dawid Law, Philipp Picej, John Neffenger, Jeremy Landis,
>>>> Daniel B.
>>>>>> Widdis, Michael Bien, Gregorz Grzybek, Kévin Buntrock, Jorge
>>> Solorzano,
>>>>>> Mark Derricutt, Matthias Bünger, Basil Crow, Romain Manni-Bucau,
>>> Thomas
>>>>>> Sundberg, Anders Hammar, Piotr P. Karwasz, Niels Basjes, Enrico
>>>> Olivelli
>>>>>>>>>
>>>>>>>>> -1: Elliotte Rusty Harold
>>>>>>>>>
>>>>>>>>> --------------
>>>>>>>>>
>>>>>>>>> 5 out of 11 binding votes are -1 with valid arguments,
>> including
>>>> that
>>>>>> there is no actual need to upgrade, that (it's too late, as ) we
>> are
>>>>>> already in RC phase, and that it might put on new constraints to
>>>> users. The
>>>>>> vote was (in line to the vote about lifting Maven 4 to Java 17) a
>>>>>> "procedural majority vote", meaing a simple majority of binding
>> votes
>>>> would
>>>>>> be enough to considered it to be passed. But due the high number of
>>>>>> negative votes and brought up arguments, I don't think we should
>>> ignore
>>>>>> them but take them into consideration for the benefit of the Maven
>>>>>> community. Therefore I call the vote to be non successful. We can
>>>>>> reevaluate in the future, including having a closer look at /
>>>> discussion
>>>>>> about the benefits and constraints of raising the Java version.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Wish you a happy sunday!
>>>>>>>>> Matthias
>>>>>>>>>
>>>>>>>>> [*1]:
>>>>>> https://lists.apache.org/thread/mjbx64vlbd346ov3l4wj6fy9vh8608vr
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>
>>>>>>
>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [RESULT][VOTE] Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Gary Gregory <ga...@gmail.com>.
There is an interesting parallel here with the what is happening in the
logo-dev mailing list: Someone calls for a vote, the results are obvious
(count the votes), then it feels like we are back to square one when some
starts haggling the whole thing over again. This might not be a bad thing,
we are not machines or anywhere near perfect but I just found it
interesting.
Gary
On Fri, May 23, 2025, 15:34 Romain Manni-Bucau <rm...@gmail.com>
wrote:
> I do not think we can use that as a point otherwise we should go with java
> 8.
> So question is really do we go with what is current when we do the final or
> do we go with a past choice assuming people not upgrading their stack will
> upgrade their stack cause maven 4 is too awesome to not upgrade.
>
> Romain Manni-Bucau
> @rmannibucau <https://x.com/rmannibucau> | .NET Blog
> <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/>
> | Old
> Blog <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064
> >
>
>
> Le ven. 23 mai 2025 à 21:05, Gary Gregory <ga...@gmail.com> a
> écrit :
>
> > On Fri, May 23, 2025, 13:40 Benjamin Marwell <bm...@apache.org>
> wrote:
> >
> > > Hey, I can totally understand the people voting -1 for the given
> reasons.
> > > Even with Java 17 support ending in ~15 months FOR PERSONAL USE.
> > > There will be a loooooong tail of extended support for money.
> > >
> >
> >
> > And how much of this moooooooney will come to Maven maintainers?
> >
> > Gary
> >
> >
> > > Anyway, my suggestion:
> > > Let's do Maven 4.0.0 with Java 17.
> > > Wait for a 4.0.1, 4.1.0... and then with Maven 4.2.0 or 4.3.0 let's
> > > look again into lifting the runtime requirement to Java 21.
> > > By then, community support is about to end and most plugins will be
> > > lifted to 17, which will give us a much tighter ecosystem.
> > >
> > > "Aufgeschoben ist nicht aufgehoben" => "Postponed is not cancelled"
> > >
> > > Does that work for you? Sounds like a reasonable common ground.
> > > It is similar to what has been done with Maven 3, no?
> > >
> > > - Ben
> > >
> > > Am Mo., 12. Mai 2025 um 23:42 Uhr schrieb Henning Schmiedehausen
> > > <he...@schmiedehausen.org.invalid>:
> > > >
> > > > As a case in point, I am slowly moving the plugins that I maintain (
> > > > https://basepom.github.io/) to Java 17 and 21, even though these are
> > > Maven
> > > > 3.x.x plugins. I will require projects that adopt those to use 17 or
> 21
> > > to
> > > > run the build. Which is fine, because I can still deliver Java 8 or
> > Java
> > > 11
> > > > compatible software even if building on a newer JDK.
> > > >
> > > > Java 17 is "end of public support" in ~ 15 months. By that time, two
> > > newer
> > > > LTS versions (21 and 25) will be available. And 21 gives a path to
> use
> > > > things like FFI which do not exist in 17.
> > > >
> > > > This decision seems to be too much on the conservative side. Anyone
> who
> > > > does not want to upgrade Java will not upgrade to Maven 4 anyway.
> > > >
> > > > -h
> > > >
> > > >
> > > >
> > > > On Sat, May 10, 2025 at 1:17 PM Tamás Cservenák <tamas@cservenak.net
> >
> > > wrote:
> > > >
> > > > > Howdy,
> > > > >
> > > > > very same sentiment over here as well. I am very disappointed with
> > the
> > > > > outcome.
> > > > >
> > > > > So, I am curious about folks voting -1...
> > > > >
> > > > > Is one of them planning to go rogue and surprise us all by doing a
> > > > > Maven 4 GA release soon? :D
> > > > >
> > > > > Thanks
> > > > >
> > > > > T
> > > > >
> > > > >
> > > > >
> > > > > On Sat, May 10, 2025 at 8:58 PM Mirko Friedenhagen
> > > > > <mf...@gmx.de.invalid> wrote:
> > > > > >
> > > > > > I completely second Manfred here:
> > > > > >
> > > > > > - People who are willing to use Maven 4 soonish should be
> > considered
> > > > > fast movers. So I guess these are already using Java 21 anyways.
> > > > > > - Going from Java 17 to 21 does not require major adaptions if
> any
> > in
> > > > > code in my experience.
> > > > > > - New LTS Java 25 comes out this year, so even 21 will not be the
> > > shiny
> > > > > new version.
> > > > > >
> > > > > > Mit freundlichen Grüßen
> > > > > > Mirko Friedenhagen
> > > > > > —
> > > > > > Sent from my mobile
> > > > > >
> > > > > > > Am 04.05.2025 um 20:45 schrieb Manfred Moser <
> > > manfred@simpligility.ca
> > > > > >:
> > > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > I find this extremely disappointing and also confusing. A
> > majority
> > > of
> > > > > binding and non-binding votes opted FOR adopting Java 21. How can
> > this
> > > be
> > > > > justified with our procedures?
> > > > > > >
> > > > > > > Here are my arguments for adopting Java 21 that seems to have
> > been
> > > > > asked for although they are imho obvious.
> > > > > > >
> > > > > > > * Maven 4 will be a brand new release with many changes. An
> > > upgrade of
> > > > > the required Java version is already included. Changing that from
> 17
> > > to 21
> > > > > does not have that much impact on users.
> > > > > > >
> > > > > > > * Java 21 is the latest current Java LTS release, and Java 25
> as
> > > the
> > > > > next LTS will be out in September .. that might even be before
> Maven
> > 4
> > > > > ships.
> > > > > > >
> > > > > > > * Java 21 has numerous improvements on top of 17 that making
> > > > > programming with it better (and newer versions are even better).
> > > > > > >
> > > > > > > * Programmers will be less inclined to help a project that uses
> > an
> > > old
> > > > > Java version (17 is 3 years old.. ) and therefore prohibits them
> for
> > > using
> > > > > modern programming styles and usage.
> > > > > > >
> > > > > > > * Performance of Java 21 is better and it is more suitable to
> run
> > > on
> > > > > containers (which is common for CI and CD systems these days.
> > > > > > >
> > > > > > > * As a project overall we should strive to provide modern
> > powerful
> > > > > tooling and that also includes using modern runtime versions and
> > taking
> > > > > advantage of new features.
> > > > > > >
> > > > > > > * A later upgrade to Java 21 in in 4.1 for example seem to make
> > > sense
> > > > > sense for a minor version update.
> > > > > > >
> > > > > > > * Holding us back to Java 17 means we can not start refactoring
> > the
> > > > > code to take advantage of features from 18, 19, 20, and 21.
> > > > > > >
> > > > > > > Beyond that I want to discount the "valid" arguments:
> > > > > > >
> > > > > > > * Procedurally there is nothing wrong with changing in the RC
> > > phase.
> > > > > There is no rule about how long that phase is and how many RCs
> there
> > > should
> > > > > be.
> > > > > > >
> > > > > > > * The new constraints on users only apply if they upgrade to
> > Maven
> > > 4
> > > > > .. which is completely optional.
> > > > > > >
> > > > > > > * Even people who voted with -1 said that they would like to
> > > upgrade
> > > > > and that it would be nice, so what is really holding this back.
> > > > > > >
> > > > > > > I therefore ask for the conclusion to be reconsidered and
> > following
> > > > > our majority rules to adopt the raise to Java 21 as requirements
> for
> > > Maven
> > > > > 4 before we release a final version.
> > > > > > >
> > > > > > > Manfred
> > > > > > >
> > > > > > >> On 2025-05-03 11:57 p.m., Matthias Bünger wrote:
> > > > > > >> Morning everyone,
> > > > > > >> first I would like to thank everybody who participated in the
> > vote
> > > > > [*1] about lifting the required Java version to 21 for Maven 4.0.0.
> > > > > > >>
> > > > > > >> The vote has ended with the following votes:
> > > > > > >>
> > > > > > >> --------------
> > > > > > >> Binding votes:
> > > > > > >>
> > > > > > >> +1: Sylwester Lachiewicz, Karl Heinz Marbaise, Tamás
> Cservenák,
> > > > > Benjamin Marwell, Arnaud Héritier, Tibor Digaňa
> > > > > > >>
> > > > > > >> -1: Michael Osipov, Maarten Mulders, Olivier Lamy, Slawomir
> > > > > Jaranowski, Hervé Boutemy
> > > > > > >>
> > > > > > >>
> > > > > > >> Non-binding votes:
> > > > > > >>
> > > > > > >> +1: Gary Gregory, Mateusz Gajewski, Mantas Gridinas, Rodrigo
> > > Bourbon,
> > > > > Willker Gomes, Hans Aikema, Martin Desruisseaux, Torsten Heit,
> Sandra
> > > > > Parsick, Dawid Law, Philipp Picej, John Neffenger, Jeremy Landis,
> > > Daniel B.
> > > > > Widdis, Michael Bien, Gregorz Grzybek, Kévin Buntrock, Jorge
> > Solorzano,
> > > > > Mark Derricutt, Matthias Bünger, Basil Crow, Romain Manni-Bucau,
> > Thomas
> > > > > Sundberg, Anders Hammar, Piotr P. Karwasz, Niels Basjes, Enrico
> > > Olivelli
> > > > > > >>
> > > > > > >> -1: Elliotte Rusty Harold
> > > > > > >>
> > > > > > >> --------------
> > > > > > >>
> > > > > > >> 5 out of 11 binding votes are -1 with valid arguments,
> including
> > > that
> > > > > there is no actual need to upgrade, that (it's too late, as ) we
> are
> > > > > already in RC phase, and that it might put on new constraints to
> > > users. The
> > > > > vote was (in line to the vote about lifting Maven 4 to Java 17) a
> > > > > "procedural majority vote", meaing a simple majority of binding
> votes
> > > would
> > > > > be enough to considered it to be passed. But due the high number of
> > > > > negative votes and brought up arguments, I don't think we should
> > ignore
> > > > > them but take them into consideration for the benefit of the Maven
> > > > > community. Therefore I call the vote to be non successful. We can
> > > > > reevaluate in the future, including having a closer look at /
> > > discussion
> > > > > about the benefits and constraints of raising the Java version.
> > > > > > >>
> > > > > > >>
> > > > > > >> Wish you a happy sunday!
> > > > > > >> Matthias
> > > > > > >>
> > > > > > >> [*1]:
> > > > > https://lists.apache.org/thread/mjbx64vlbd346ov3l4wj6fy9vh8608vr
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > ---------------------------------------------------------------------
> > > > > > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > >> For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > >>
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
Re: [RESULT][VOTE] Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
I do not think we can use that as a point otherwise we should go with java
8.
So question is really do we go with what is current when we do the final or
do we go with a past choice assuming people not upgrading their stack will
upgrade their stack cause maven 4 is too awesome to not upgrade.
Romain Manni-Bucau
@rmannibucau <https://x.com/rmannibucau> | .NET Blog
<https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old
Blog <http://rmannibucau.wordpress.com> | Github
<https://github.com/rmannibucau> | LinkedIn
<https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064>
Le ven. 23 mai 2025 à 21:05, Gary Gregory <ga...@gmail.com> a écrit :
> On Fri, May 23, 2025, 13:40 Benjamin Marwell <bm...@apache.org> wrote:
>
> > Hey, I can totally understand the people voting -1 for the given reasons.
> > Even with Java 17 support ending in ~15 months FOR PERSONAL USE.
> > There will be a loooooong tail of extended support for money.
> >
>
>
> And how much of this moooooooney will come to Maven maintainers?
>
> Gary
>
>
> > Anyway, my suggestion:
> > Let's do Maven 4.0.0 with Java 17.
> > Wait for a 4.0.1, 4.1.0... and then with Maven 4.2.0 or 4.3.0 let's
> > look again into lifting the runtime requirement to Java 21.
> > By then, community support is about to end and most plugins will be
> > lifted to 17, which will give us a much tighter ecosystem.
> >
> > "Aufgeschoben ist nicht aufgehoben" => "Postponed is not cancelled"
> >
> > Does that work for you? Sounds like a reasonable common ground.
> > It is similar to what has been done with Maven 3, no?
> >
> > - Ben
> >
> > Am Mo., 12. Mai 2025 um 23:42 Uhr schrieb Henning Schmiedehausen
> > <he...@schmiedehausen.org.invalid>:
> > >
> > > As a case in point, I am slowly moving the plugins that I maintain (
> > > https://basepom.github.io/) to Java 17 and 21, even though these are
> > Maven
> > > 3.x.x plugins. I will require projects that adopt those to use 17 or 21
> > to
> > > run the build. Which is fine, because I can still deliver Java 8 or
> Java
> > 11
> > > compatible software even if building on a newer JDK.
> > >
> > > Java 17 is "end of public support" in ~ 15 months. By that time, two
> > newer
> > > LTS versions (21 and 25) will be available. And 21 gives a path to use
> > > things like FFI which do not exist in 17.
> > >
> > > This decision seems to be too much on the conservative side. Anyone who
> > > does not want to upgrade Java will not upgrade to Maven 4 anyway.
> > >
> > > -h
> > >
> > >
> > >
> > > On Sat, May 10, 2025 at 1:17 PM Tamás Cservenák <ta...@cservenak.net>
> > wrote:
> > >
> > > > Howdy,
> > > >
> > > > very same sentiment over here as well. I am very disappointed with
> the
> > > > outcome.
> > > >
> > > > So, I am curious about folks voting -1...
> > > >
> > > > Is one of them planning to go rogue and surprise us all by doing a
> > > > Maven 4 GA release soon? :D
> > > >
> > > > Thanks
> > > >
> > > > T
> > > >
> > > >
> > > >
> > > > On Sat, May 10, 2025 at 8:58 PM Mirko Friedenhagen
> > > > <mf...@gmx.de.invalid> wrote:
> > > > >
> > > > > I completely second Manfred here:
> > > > >
> > > > > - People who are willing to use Maven 4 soonish should be
> considered
> > > > fast movers. So I guess these are already using Java 21 anyways.
> > > > > - Going from Java 17 to 21 does not require major adaptions if any
> in
> > > > code in my experience.
> > > > > - New LTS Java 25 comes out this year, so even 21 will not be the
> > shiny
> > > > new version.
> > > > >
> > > > > Mit freundlichen Grüßen
> > > > > Mirko Friedenhagen
> > > > > —
> > > > > Sent from my mobile
> > > > >
> > > > > > Am 04.05.2025 um 20:45 schrieb Manfred Moser <
> > manfred@simpligility.ca
> > > > >:
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > I find this extremely disappointing and also confusing. A
> majority
> > of
> > > > binding and non-binding votes opted FOR adopting Java 21. How can
> this
> > be
> > > > justified with our procedures?
> > > > > >
> > > > > > Here are my arguments for adopting Java 21 that seems to have
> been
> > > > asked for although they are imho obvious.
> > > > > >
> > > > > > * Maven 4 will be a brand new release with many changes. An
> > upgrade of
> > > > the required Java version is already included. Changing that from 17
> > to 21
> > > > does not have that much impact on users.
> > > > > >
> > > > > > * Java 21 is the latest current Java LTS release, and Java 25 as
> > the
> > > > next LTS will be out in September .. that might even be before Maven
> 4
> > > > ships.
> > > > > >
> > > > > > * Java 21 has numerous improvements on top of 17 that making
> > > > programming with it better (and newer versions are even better).
> > > > > >
> > > > > > * Programmers will be less inclined to help a project that uses
> an
> > old
> > > > Java version (17 is 3 years old.. ) and therefore prohibits them for
> > using
> > > > modern programming styles and usage.
> > > > > >
> > > > > > * Performance of Java 21 is better and it is more suitable to run
> > on
> > > > containers (which is common for CI and CD systems these days.
> > > > > >
> > > > > > * As a project overall we should strive to provide modern
> powerful
> > > > tooling and that also includes using modern runtime versions and
> taking
> > > > advantage of new features.
> > > > > >
> > > > > > * A later upgrade to Java 21 in in 4.1 for example seem to make
> > sense
> > > > sense for a minor version update.
> > > > > >
> > > > > > * Holding us back to Java 17 means we can not start refactoring
> the
> > > > code to take advantage of features from 18, 19, 20, and 21.
> > > > > >
> > > > > > Beyond that I want to discount the "valid" arguments:
> > > > > >
> > > > > > * Procedurally there is nothing wrong with changing in the RC
> > phase.
> > > > There is no rule about how long that phase is and how many RCs there
> > should
> > > > be.
> > > > > >
> > > > > > * The new constraints on users only apply if they upgrade to
> Maven
> > 4
> > > > .. which is completely optional.
> > > > > >
> > > > > > * Even people who voted with -1 said that they would like to
> > upgrade
> > > > and that it would be nice, so what is really holding this back.
> > > > > >
> > > > > > I therefore ask for the conclusion to be reconsidered and
> following
> > > > our majority rules to adopt the raise to Java 21 as requirements for
> > Maven
> > > > 4 before we release a final version.
> > > > > >
> > > > > > Manfred
> > > > > >
> > > > > >> On 2025-05-03 11:57 p.m., Matthias Bünger wrote:
> > > > > >> Morning everyone,
> > > > > >> first I would like to thank everybody who participated in the
> vote
> > > > [*1] about lifting the required Java version to 21 for Maven 4.0.0.
> > > > > >>
> > > > > >> The vote has ended with the following votes:
> > > > > >>
> > > > > >> --------------
> > > > > >> Binding votes:
> > > > > >>
> > > > > >> +1: Sylwester Lachiewicz, Karl Heinz Marbaise, Tamás Cservenák,
> > > > Benjamin Marwell, Arnaud Héritier, Tibor Digaňa
> > > > > >>
> > > > > >> -1: Michael Osipov, Maarten Mulders, Olivier Lamy, Slawomir
> > > > Jaranowski, Hervé Boutemy
> > > > > >>
> > > > > >>
> > > > > >> Non-binding votes:
> > > > > >>
> > > > > >> +1: Gary Gregory, Mateusz Gajewski, Mantas Gridinas, Rodrigo
> > Bourbon,
> > > > Willker Gomes, Hans Aikema, Martin Desruisseaux, Torsten Heit, Sandra
> > > > Parsick, Dawid Law, Philipp Picej, John Neffenger, Jeremy Landis,
> > Daniel B.
> > > > Widdis, Michael Bien, Gregorz Grzybek, Kévin Buntrock, Jorge
> Solorzano,
> > > > Mark Derricutt, Matthias Bünger, Basil Crow, Romain Manni-Bucau,
> Thomas
> > > > Sundberg, Anders Hammar, Piotr P. Karwasz, Niels Basjes, Enrico
> > Olivelli
> > > > > >>
> > > > > >> -1: Elliotte Rusty Harold
> > > > > >>
> > > > > >> --------------
> > > > > >>
> > > > > >> 5 out of 11 binding votes are -1 with valid arguments, including
> > that
> > > > there is no actual need to upgrade, that (it's too late, as ) we are
> > > > already in RC phase, and that it might put on new constraints to
> > users. The
> > > > vote was (in line to the vote about lifting Maven 4 to Java 17) a
> > > > "procedural majority vote", meaing a simple majority of binding votes
> > would
> > > > be enough to considered it to be passed. But due the high number of
> > > > negative votes and brought up arguments, I don't think we should
> ignore
> > > > them but take them into consideration for the benefit of the Maven
> > > > community. Therefore I call the vote to be non successful. We can
> > > > reevaluate in the future, including having a closer look at /
> > discussion
> > > > about the benefits and constraints of raising the Java version.
> > > > > >>
> > > > > >>
> > > > > >> Wish you a happy sunday!
> > > > > >> Matthias
> > > > > >>
> > > > > >> [*1]:
> > > > https://lists.apache.org/thread/mjbx64vlbd346ov3l4wj6fy9vh8608vr
> > > > > >>
> > > > > >>
> > > > > >>
> > ---------------------------------------------------------------------
> > > > > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > >> For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >>
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > > >
> > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: [RESULT][VOTE] Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, May 23, 2025, 13:40 Benjamin Marwell <bm...@apache.org> wrote:
> Hey, I can totally understand the people voting -1 for the given reasons.
> Even with Java 17 support ending in ~15 months FOR PERSONAL USE.
> There will be a loooooong tail of extended support for money.
>
And how much of this moooooooney will come to Maven maintainers?
Gary
> Anyway, my suggestion:
> Let's do Maven 4.0.0 with Java 17.
> Wait for a 4.0.1, 4.1.0... and then with Maven 4.2.0 or 4.3.0 let's
> look again into lifting the runtime requirement to Java 21.
> By then, community support is about to end and most plugins will be
> lifted to 17, which will give us a much tighter ecosystem.
>
> "Aufgeschoben ist nicht aufgehoben" => "Postponed is not cancelled"
>
> Does that work for you? Sounds like a reasonable common ground.
> It is similar to what has been done with Maven 3, no?
>
> - Ben
>
> Am Mo., 12. Mai 2025 um 23:42 Uhr schrieb Henning Schmiedehausen
> <he...@schmiedehausen.org.invalid>:
> >
> > As a case in point, I am slowly moving the plugins that I maintain (
> > https://basepom.github.io/) to Java 17 and 21, even though these are
> Maven
> > 3.x.x plugins. I will require projects that adopt those to use 17 or 21
> to
> > run the build. Which is fine, because I can still deliver Java 8 or Java
> 11
> > compatible software even if building on a newer JDK.
> >
> > Java 17 is "end of public support" in ~ 15 months. By that time, two
> newer
> > LTS versions (21 and 25) will be available. And 21 gives a path to use
> > things like FFI which do not exist in 17.
> >
> > This decision seems to be too much on the conservative side. Anyone who
> > does not want to upgrade Java will not upgrade to Maven 4 anyway.
> >
> > -h
> >
> >
> >
> > On Sat, May 10, 2025 at 1:17 PM Tamás Cservenák <ta...@cservenak.net>
> wrote:
> >
> > > Howdy,
> > >
> > > very same sentiment over here as well. I am very disappointed with the
> > > outcome.
> > >
> > > So, I am curious about folks voting -1...
> > >
> > > Is one of them planning to go rogue and surprise us all by doing a
> > > Maven 4 GA release soon? :D
> > >
> > > Thanks
> > >
> > > T
> > >
> > >
> > >
> > > On Sat, May 10, 2025 at 8:58 PM Mirko Friedenhagen
> > > <mf...@gmx.de.invalid> wrote:
> > > >
> > > > I completely second Manfred here:
> > > >
> > > > - People who are willing to use Maven 4 soonish should be considered
> > > fast movers. So I guess these are already using Java 21 anyways.
> > > > - Going from Java 17 to 21 does not require major adaptions if any in
> > > code in my experience.
> > > > - New LTS Java 25 comes out this year, so even 21 will not be the
> shiny
> > > new version.
> > > >
> > > > Mit freundlichen Grüßen
> > > > Mirko Friedenhagen
> > > > —
> > > > Sent from my mobile
> > > >
> > > > > Am 04.05.2025 um 20:45 schrieb Manfred Moser <
> manfred@simpligility.ca
> > > >:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > I find this extremely disappointing and also confusing. A majority
> of
> > > binding and non-binding votes opted FOR adopting Java 21. How can this
> be
> > > justified with our procedures?
> > > > >
> > > > > Here are my arguments for adopting Java 21 that seems to have been
> > > asked for although they are imho obvious.
> > > > >
> > > > > * Maven 4 will be a brand new release with many changes. An
> upgrade of
> > > the required Java version is already included. Changing that from 17
> to 21
> > > does not have that much impact on users.
> > > > >
> > > > > * Java 21 is the latest current Java LTS release, and Java 25 as
> the
> > > next LTS will be out in September .. that might even be before Maven 4
> > > ships.
> > > > >
> > > > > * Java 21 has numerous improvements on top of 17 that making
> > > programming with it better (and newer versions are even better).
> > > > >
> > > > > * Programmers will be less inclined to help a project that uses an
> old
> > > Java version (17 is 3 years old.. ) and therefore prohibits them for
> using
> > > modern programming styles and usage.
> > > > >
> > > > > * Performance of Java 21 is better and it is more suitable to run
> on
> > > containers (which is common for CI and CD systems these days.
> > > > >
> > > > > * As a project overall we should strive to provide modern powerful
> > > tooling and that also includes using modern runtime versions and taking
> > > advantage of new features.
> > > > >
> > > > > * A later upgrade to Java 21 in in 4.1 for example seem to make
> sense
> > > sense for a minor version update.
> > > > >
> > > > > * Holding us back to Java 17 means we can not start refactoring the
> > > code to take advantage of features from 18, 19, 20, and 21.
> > > > >
> > > > > Beyond that I want to discount the "valid" arguments:
> > > > >
> > > > > * Procedurally there is nothing wrong with changing in the RC
> phase.
> > > There is no rule about how long that phase is and how many RCs there
> should
> > > be.
> > > > >
> > > > > * The new constraints on users only apply if they upgrade to Maven
> 4
> > > .. which is completely optional.
> > > > >
> > > > > * Even people who voted with -1 said that they would like to
> upgrade
> > > and that it would be nice, so what is really holding this back.
> > > > >
> > > > > I therefore ask for the conclusion to be reconsidered and following
> > > our majority rules to adopt the raise to Java 21 as requirements for
> Maven
> > > 4 before we release a final version.
> > > > >
> > > > > Manfred
> > > > >
> > > > >> On 2025-05-03 11:57 p.m., Matthias Bünger wrote:
> > > > >> Morning everyone,
> > > > >> first I would like to thank everybody who participated in the vote
> > > [*1] about lifting the required Java version to 21 for Maven 4.0.0.
> > > > >>
> > > > >> The vote has ended with the following votes:
> > > > >>
> > > > >> --------------
> > > > >> Binding votes:
> > > > >>
> > > > >> +1: Sylwester Lachiewicz, Karl Heinz Marbaise, Tamás Cservenák,
> > > Benjamin Marwell, Arnaud Héritier, Tibor Digaňa
> > > > >>
> > > > >> -1: Michael Osipov, Maarten Mulders, Olivier Lamy, Slawomir
> > > Jaranowski, Hervé Boutemy
> > > > >>
> > > > >>
> > > > >> Non-binding votes:
> > > > >>
> > > > >> +1: Gary Gregory, Mateusz Gajewski, Mantas Gridinas, Rodrigo
> Bourbon,
> > > Willker Gomes, Hans Aikema, Martin Desruisseaux, Torsten Heit, Sandra
> > > Parsick, Dawid Law, Philipp Picej, John Neffenger, Jeremy Landis,
> Daniel B.
> > > Widdis, Michael Bien, Gregorz Grzybek, Kévin Buntrock, Jorge Solorzano,
> > > Mark Derricutt, Matthias Bünger, Basil Crow, Romain Manni-Bucau, Thomas
> > > Sundberg, Anders Hammar, Piotr P. Karwasz, Niels Basjes, Enrico
> Olivelli
> > > > >>
> > > > >> -1: Elliotte Rusty Harold
> > > > >>
> > > > >> --------------
> > > > >>
> > > > >> 5 out of 11 binding votes are -1 with valid arguments, including
> that
> > > there is no actual need to upgrade, that (it's too late, as ) we are
> > > already in RC phase, and that it might put on new constraints to
> users. The
> > > vote was (in line to the vote about lifting Maven 4 to Java 17) a
> > > "procedural majority vote", meaing a simple majority of binding votes
> would
> > > be enough to considered it to be passed. But due the high number of
> > > negative votes and brought up arguments, I don't think we should ignore
> > > them but take them into consideration for the benefit of the Maven
> > > community. Therefore I call the vote to be non successful. We can
> > > reevaluate in the future, including having a closer look at /
> discussion
> > > about the benefits and constraints of raising the Java version.
> > > > >>
> > > > >>
> > > > >> Wish you a happy sunday!
> > > > >> Matthias
> > > > >>
> > > > >> [*1]:
> > > https://lists.apache.org/thread/mjbx64vlbd346ov3l4wj6fy9vh8608vr
> > > > >>
> > > > >>
> > > > >>
> ---------------------------------------------------------------------
> > > > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > >> For additional commands, e-mail: dev-help@maven.apache.org
> > > > >>
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [RESULT][VOTE] Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Karl Heinz Marbaise <kh...@gmx.de.INVALID>.
Hi,
all the points based on Java 8/11/17 is supported for a long time, does
not really make sense from my point of view, because you can create code
for JDK 8 even with JDK 21 (you get warnings about that; different
story) and for those edge cases where it really requires a different
JDK, you can use toolchains which existing very very long. Or you might
using Maven 3.X anyway...
In the VOTE for JDK 17 the same arguments have been given. My opinion
is to go for JDK 21... because in September the next LTS JDK 25 will be
released...
Kind regards
Karl Heinz Marbaise
On 24.05.25 15:16, Tamás Cservenák wrote:
> ... aaand because some company/ies does/do that,
> we as an open source project/forget need/must stick to it?
>
> So basically, all we did so far was "waste of resources"
> as Java 8 is there to stay, at least until 2030, right?
> Why did we bother at all!
>
>
> On Sat, May 24, 2025 at 3:10 PM Elliotte Rusty Harold
> <el...@ibiblio.org> wrote:
>>
>> On Fri, May 23, 2025 at 5:38 PM Benjamin Marwell <bm...@apache.org> wrote:
>>>
>>> Hey, I can totally understand the people voting -1 for the given reasons.
>>> Even with Java 17 support ending in ~15 months FOR PERSONAL USE.
>>
>>
>> This is **NOT** true, though people keep repeating this. Java 8, 11,
>> and 17 will be supported for some time to come. Oracle might stop
>> supporting them. Oracle != Java. For example, Amazon has commited "to
>> provide performance enhancements and security updates at no cost until
>> at least the specified date for the relevant release version (e.g.
>> December 2030 for Corretto 8)." There are many other vendors.
>>
>> --
>> Elliotte Rusty Harold
>> elharo@ibiblio.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Guillaume Nodet <gn...@apache.org>.
------------------------
Guillaume Nodet
Le dim. 25 mai 2025 à 13:30, Elliotte Rusty Harold <el...@ibiblio.org> a
écrit :
>
> As much as I would like to rip out Modello and chuck it into the
> Mariana trench, I don't think that's likely to happen.
Why is that so ? If you want to replace it with something else, I’d be
fine. We’re mostly using velocity templates, so the two things we’re using
from modello now are: the modello model and the xsd generator. But if
what you want is get rid of code generation, I don’t see why we would want
to add maintenance burden (manually maintaining hundreds of classes)
instead of less.
Consequently
> this is a non-starter. If you do manage to rip out and replace
> Modello, then we can talk about record classes, but I don't want to
> have both Modello and record classes, which is what would likely
> happen if we tried this today.
I don’t see why both are related. A single change to the velocity
templates (which is in the maven core source code, not modello) would allow
the switch. That sounds like a good idea to give it a try to me.
>
>
> > Java 24+ (in a later Maven version) for class-file API. It would resolve
> > at least some of the compatibility problems observed when new Java
> > versions are released and Maven wants to analyse the byte code.
>
> This one is interesting. Unfortunately it's far too early to require
> Java 24+ for users, which is what we'd need for this, since users
> would need to run code that calls this API. I don't want to predict
> exactly when this will be possible. However, it's multiple years away.
> Most big dev shops are extremely slow to upgrade. 3 years ago when I
> left Google, they had just finished a multi-year company wide
> migration to Java 11. Meta isn't as big a Java shop, but they too were
> using Java 11 at least through late 2024. They and others will
> eventually get to Java 25, but that's years in the future.
If big shops are slow to upgrade, we don’t have to care about them, as I
doubt this is only the case for the JDK. It will also concern Maven, so I
don’t see why we should bother taking them into account since they won’t
be using Maven 4 before years anyway.
>
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Gary Gregory <ga...@gmail.com>.
On Sun, May 25, 2025, 14:40 Tamás Cservenák <ta...@cservenak.net> wrote:
> > As repeated many times on this mailing list, JPMS is opt-in.
>
> For the sake of Maven users we have to _clearly_ communicate these things:
>
> - Maven4 will try to give "first class citizen" support for JPMS
> - BUT, it is opt-in, in a way, if user decides to NOT use JPMS, no
> change is needed on user side
>
> In other words, if you don't use JPMS, you can just ignore it, and
> just use Maven 4 as you did so far with Maven3.
>
> But, if you do want to use it, it will allow you to fully express your
> setup (declaratively), instead as today, where you had to rely on
> hacks, some sort of heuristics and a lot of luck ("will it work?") :)
>
Or try to do what we do in Commons and use the Moditect Maven plugin. It
seems to cover most of not all use cases.
Gary
>
> (In general, I always tried (and assumed everyone else is doing the
> same) to deliver some Maven "new feature", IF it would in any way
> interfere with existing builds to leave it "dormant", in a way that
> new feature needs conscious user decision, some config, switch.
> whatever to become active. There was ONE exception to this on my side:
> the new JDK HTTP transport. But even in this case, we always provide
> "escape hatch")
>
> Thanks
> T
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Tamás Cservenák <ta...@cservenak.net>.
> As repeated many times on this mailing list, JPMS is opt-in.
For the sake of Maven users we have to _clearly_ communicate these things:
- Maven4 will try to give "first class citizen" support for JPMS
- BUT, it is opt-in, in a way, if user decides to NOT use JPMS, no
change is needed on user side
In other words, if you don't use JPMS, you can just ignore it, and
just use Maven 4 as you did so far with Maven3.
But, if you do want to use it, it will allow you to fully express your
setup (declaratively), instead as today, where you had to rely on
hacks, some sort of heuristics and a lot of luck ("will it work?") :)
(In general, I always tried (and assumed everyone else is doing the
same) to deliver some Maven "new feature", IF it would in any way
interfere with existing builds to leave it "dormant", in a way that
new feature needs conscious user decision, some config, switch.
whatever to become active. There was ONE exception to this on my side:
the new JDK HTTP transport. But even in this case, we always provide
"escape hatch")
Thanks
T
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 2025-05-25 à 19 h 12, Hunter C Payne a écrit :
> My experiences with JPMS have been universally been bad.
>
Your experience of JPMS, or your experience of Maven 3 / Gradle support
of JPMS?
> If you are going to do this, you need to make the default for it to be
> completely disabled.
>
As repeated many times on this mailing list, JPMS is opt-in.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Jorge Solorzano <jo...@gmail.com>.
On Sun, May 25, 2025 at 7:14 PM Hunter C Payne
<hu...@yahoo.com.invalid> wrote:
>
> I believe JPMS has been around for something like 15 years. And after 15 years of pushing it hard, it doesn't seem like it is used by too many people.
Java 9 introduced the Java Platform Module System (JPMS) in September
2017 — just eight years ago, not 15. Many "enterprises" remain on Java
8 due to legacy constraints, limited migration incentives, or risk
aversion. Even within open source ecosystems, adoption of JPMS has
been limited, despite its clear benefits for modularity and
encapsulation. In that context, eight years is not a long time — but
even so, there hasn’t been a significant or coordinated push to
promote JPMS adoption.
> If people are not using it by now, how good of an idea is it to push it now? I feel like the market has spoken (over and over again) on this topic. My experiences with JPMS have been universally been bad. If you are going to do this, you need to make the default for it to be completely disabled. If you don't, don't expect adoption of M4.
As Martin mentions, this is your experience of JPMS, or your
experience of Maven 3 / Gradle support of JPMS?
In my experience, JPMS has helped me write better-structured code.
Adopting a modular mindset is challenging at first, but once
understood, it pays off. That said, I recognize that many developers
prioritize speed and convenience over clean architecture — leading to
issues like split packages and poorly designed APIs becoming the norm.
What I found most difficult was the lack of tooling support. Tools
like Maven 3 and Eclipse IDE had limited support for JPMS, which
forced me to implement awkward workarounds — especially when working
with multi-release JARs (MR-JARs), where support was almost
nonexistent. If Maven 4 addresses these limitations, it would be a
much-needed improvement for developers looking to adopt JPMS more
seriously.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Hunter C Payne <hu...@yahoo.com.INVALID>.
I believe JPMS has been around for something like 15 years. And after 15 years of pushing it hard, it doesn't seem like it is used by too many people. If people are not using it by now, how good of an idea is it to push it now? I feel like the market has spoken (over and over again) on this topic. My experiences with JPMS have been universally been bad. If you are going to do this, you need to make the default for it to be completely disabled. If you don't, don't expect adoption of M4.
Hunter
On Sunday, May 25, 2025 at 10:04:23 AM PDT, Martin Desruisseaux <ma...@geomatys.com> wrote:
Le 2025-05-25 à 13 h 28, Elliotte Rusty Harold a écrit :
> Can you be more specific? Is there some code we need to produce or
> compile that we cannot compile with Java 8?
>
Yes. Maven 4 core and the compiler plugin 4.0.0-beta already got the
following Java 9+ dependencies:
* MODULE_PATH, UPGRADE_MODULE_PATH, PATCH_MODULE_PATH,
ANNOTATION_PROCESSOR_MODULE_PATH enumeration values of
javax.tools.StandardLocation (used in
org.apache.maven.api.JavaPathType).
* java.lang.module.ModuleDescriptor (used in
org.apache.maven.impl.DefaultDependencyResolverResult).
* javax.tools.StandardJavaFileManager.setLocationForModule(...) and
related methods (used in compiler plugin).
* Maybe more that I forgot.
> We are still trying to figure out how to lay out code for multi-module
> projects.
>
The choice is left to users. The discussion was only about the *default*
layout, and the difficulty was not in JPMS per se but in finding a
compromise with Maven 3 habits.
> That we haven't yet figured this out and haven't really needed to.
> suggests that maybe multi-module projects aren't all that important in
> the real world.
>
I think that the problem is rather widespread misunderstanding about
JPMS, in part by lack of user's experience since JPMS is difficult to
leverage fully in Maven 3 and Gradle. This is suggested by the fact that
we see peoples blaming JPMS for what are Maven and Gradle problems (lack
of control on class-path versus module-path, way to compile tests). See
also next paragraph.
> JPMS has pretty much failed. It's not clear it was ever needed in the
> first place.
>
Before to said that JPMS failed, let first give it a real chance with
real support in Maven 4. Needs exist without peoples realizing it. For
example, Maven recently puts in place a mechanism based on ClassLoader
for isolating the dependencies of a plugin from other plugins (e.g. if a
plugin uses Log4J, do not bring LogJ4 in the environment of all other
plugins). If Maven was using JPMS, this isolation would be supported
natively with no need for extra complexity (except in case of
conflicting versions, but we can still manage with java.lang.ModuleLayer).
Another need seen in my work is reducing the "class-path hell" such as
dependencies put twice with different versions. Not everyone use the
Maven enforcer plugin. This is another example of service that could be
handled natively by JPMS instead of adding another layer of complexity.
It has been reported that JPMS improves JVM startup time, but I didn't
benchmark myself.
> That said, I would like to be able to support multi-module builds, but
> what exactly can't we do without requiring Java 11?
>
Using the module-specific API of javax.tools for compilation and javadoc
generation.
> There's plenty of Java 8 code that is fully compatible with JPMS.
>
They can be partially compatible with some work duplication. For
example, services declared in META-INF/services must be repeated in
module-info, with a risk of inconsistency if the developer updates the
former but forgot to also update the latter. But if, for example, an
application loads JAR files dynamically, then it cannot be fully
compatible with JPMS without using Java 9+ API. Using
java.lang.ClassLoader alone loads the JAR file as if it was on the
class-path. If the developer wants to load the JAR file as if it was on
the module-path, she needs to use java.lang.ModuleLayer.
> All that said, if you can demonstrate in detail that Java 11 is
> required for Maven to build projects that use JPMS, and we have a plan
> for addressing everything else needed to support multi-module builds,
> then I would find that a compelling reason to require Java 11.
>
I have more than a plan: it is almost done for the compiler plugin, and
I started to look at the other plugins. Java 11 is required, we need all
the API listed at the beginning of this email, this is already
integrated in Maven 4 + compiler plugin 4.0.0-beta and already deployed
on Maven central (the deployed versions do not yet offer full JPMS
support however). The compiler plugin on the master branch already
offers full multi-modules support for compiling the main code. The work
is also completed for compiling the test code, but that work has not
been merged yet. Details there:
* https://github.com/Geomatys/maven/wiki
* https://github.com/Geomatys/maven-compiler-plugin/wiki
We need to also update the resources, javadoc and Surefire. I'm working
on that.
>> Java 16+ for starting the migration to records.
>>
> As much as I would like to rip out Modello and chuck it into the
> Mariana trench, I don't think that's likely to happen. Consequently
> this is a non-starter.
>
The plan is not te remove Modello, but to modify the code that it
generates. There is also various classes not generated by modello that
would be done manually.
Martin
Re: Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 2025-05-25 à 13 h 28, Elliotte Rusty Harold a écrit :
> Can you be more specific? Is there some code we need to produce or
> compile that we cannot compile with Java 8?
>
Yes. Maven 4 core and the compiler plugin 4.0.0-beta already got the
following Java 9+ dependencies:
* MODULE_PATH, UPGRADE_MODULE_PATH, PATCH_MODULE_PATH,
ANNOTATION_PROCESSOR_MODULE_PATH enumeration values of
javax.tools.StandardLocation (used in
org.apache.maven.api.JavaPathType).
* java.lang.module.ModuleDescriptor (used in
org.apache.maven.impl.DefaultDependencyResolverResult).
* javax.tools.StandardJavaFileManager.setLocationForModule(...) and
related methods (used in compiler plugin).
* Maybe more that I forgot.
> We are still trying to figure out how to lay out code for multi-module
> projects.
>
The choice is left to users. The discussion was only about the *default*
layout, and the difficulty was not in JPMS per se but in finding a
compromise with Maven 3 habits.
> That we haven't yet figured this out and haven't really needed to.
> suggests that maybe multi-module projects aren't all that important in
> the real world.
>
I think that the problem is rather widespread misunderstanding about
JPMS, in part by lack of user's experience since JPMS is difficult to
leverage fully in Maven 3 and Gradle. This is suggested by the fact that
we see peoples blaming JPMS for what are Maven and Gradle problems (lack
of control on class-path versus module-path, way to compile tests). See
also next paragraph.
> JPMS has pretty much failed. It's not clear it was ever needed in the
> first place.
>
Before to said that JPMS failed, let first give it a real chance with
real support in Maven 4. Needs exist without peoples realizing it. For
example, Maven recently puts in place a mechanism based on ClassLoader
for isolating the dependencies of a plugin from other plugins (e.g. if a
plugin uses Log4J, do not bring LogJ4 in the environment of all other
plugins). If Maven was using JPMS, this isolation would be supported
natively with no need for extra complexity (except in case of
conflicting versions, but we can still manage with java.lang.ModuleLayer).
Another need seen in my work is reducing the "class-path hell" such as
dependencies put twice with different versions. Not everyone use the
Maven enforcer plugin. This is another example of service that could be
handled natively by JPMS instead of adding another layer of complexity.
It has been reported that JPMS improves JVM startup time, but I didn't
benchmark myself.
> That said, I would like to be able to support multi-module builds, but
> what exactly can't we do without requiring Java 11?
>
Using the module-specific API of javax.tools for compilation and javadoc
generation.
> There's plenty of Java 8 code that is fully compatible with JPMS.
>
They can be partially compatible with some work duplication. For
example, services declared in META-INF/services must be repeated in
module-info, with a risk of inconsistency if the developer updates the
former but forgot to also update the latter. But if, for example, an
application loads JAR files dynamically, then it cannot be fully
compatible with JPMS without using Java 9+ API. Using
java.lang.ClassLoader alone loads the JAR file as if it was on the
class-path. If the developer wants to load the JAR file as if it was on
the module-path, she needs to use java.lang.ModuleLayer.
> All that said, if you can demonstrate in detail that Java 11 is
> required for Maven to build projects that use JPMS, and we have a plan
> for addressing everything else needed to support multi-module builds,
> then I would find that a compelling reason to require Java 11.
>
I have more than a plan: it is almost done for the compiler plugin, and
I started to look at the other plugins. Java 11 is required, we need all
the API listed at the beginning of this email, this is already
integrated in Maven 4 + compiler plugin 4.0.0-beta and already deployed
on Maven central (the deployed versions do not yet offer full JPMS
support however). The compiler plugin on the master branch already
offers full multi-modules support for compiling the main code. The work
is also completed for compiling the test code, but that work has not
been merged yet. Details there:
* https://github.com/Geomatys/maven/wiki
* https://github.com/Geomatys/maven-compiler-plugin/wiki
We need to also update the resources, javadoc and Surefire. I'm working
on that.
>> Java 16+ for starting the migration to records.
>>
> As much as I would like to rip out Modello and chuck it into the
> Mariana trench, I don't think that's likely to happen. Consequently
> this is a non-starter.
>
The plan is not te remove Modello, but to modify the code that it
generates. There is also various classes not generated by modello that
would be done manually.
Martin
Re: Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Jpms is not a topic, you can use jpms and mjars using a makefilr do maven
can be rewritten in go and it would work (otherwise toolchain and java
min+n couldn't work).
Now to be concrete: how to we exit this thread, vote is quite pointless and
will be in loop I fear so we need a way to move forward.
Do we expect a list of people listing features from maven 4 they want on
legacy project in the oss land to prove java < 21 is required or do we just
use java 21 until needed (we can always revert to java 17, wouldnt be the
first time at apache), enables to move forward without blocking anyone
really willing to adopt M4 (not just playing).
Le dim. 25 mai 2025, 13:51, Tamás Cservenák <ta...@cservenak.net> a écrit :
> Eliotte,
>
> While I sometimes find your hunting and fishing stories
> amusing, I also find them very tiresome.
>
> Maven is not a subcontractor or anything like that for any
> of the companies you keep talking about. Maven is not
> (contractually or in any other way) obliged to "deliver
> best experience" or even "support" to those companies
> you keep talking about.
>
> As it was said multiple times here, they are most probably
> happily using Maven3 and will keep using it.
>
> Please stop parroting these things _in relation_ to Maven 4.
>
> This is getting VERY demotivating, at least to me.
>
> I am here to have fun, and not to present some
> "corporate HOWTOs" I had experienced in my life
> (and very much hated). I understand your professional
> past had this and that taught you, but this is not your job.
> You are not better or worse by fixing or not fixing bugs
> here (or introducing them by doing other changes). This is
> an open source project, that does not account for
> spent hours, milestones and what not. Here
> the "do not touch until broken" is not in effect,
> as we do not aim for profit. There is no profit involved here.
> There is nothing "corporate" around here,
> this is supposed to be FUN.
>
> (in fact, there is: profit is when you have chance to
> sit with any of other maven-ers and have a beer with them,
> spend good time as you would with your friends,
> and NOT company coworkers. But this stands even
> for "online" chats, playing CSGO etc)
>
> So, I kindly ask you: Please stop.
>
> On Sun, May 25, 2025 at 1:30 PM Elliotte Rusty Harold
> <el...@ibiblio.org> wrote:
> >
> > On Sat, May 24, 2025 at 6:22 PM Martin Desruisseaux
> > <ma...@geomatys.com> wrote:
> >
> > > Java 9+ for supporting JPMS. This is needed not only in some plugins
> > > (compiler, javadoc, maybe surefire), but also in some places of Maven
> > > core (class-path versus module-path, cache of module-info). Even if not
> > > everyone is interested in JPMS, trying to enable JPMS while preserving
> > > Java 8 compatibility (e.g. with reflection) would have been difficult.
> >
> > Can you be more specific? Is there some code we need to produce or
> > compile that we cannot compile with Java 8? We are still trying to
> > figure out how to lay out code for multi-module projects. That we
> > haven't yet figured this out and haven't really needed to. suggests
> > that maybe multi-module projects aren't all that important in the real
> > world. JPMS has pretty much failed. It's not clear it was ever needed
> > in the first place. That said, I would like to be able to support
> > multi-module builds, but what exactly can't we do without requiring
> > Java 11? There's plenty of Java 8 code that is fully compatible with
> > JPMS. There's also some that isn't, typically due to split packages.
> > However, those problems aren't resolved by upgrading the JDK. In fact,
> > that's a reason a lot of projects avoid JPMS completely. All that
> > said, if you can demonstrate in detail that Java 11 is required for
> > Maven to build projects that use JPMS, and we have a plan for
> > addressing everything else needed to support multi-module builds, then
> > I would find that a compelling reason to require Java 11. It isn't
> > easy though. I took a run at this myself during quarantine and got
> > nowhere.
> >
> > > Java 16+ for starting the migration to records. Some data structures in
> > > Maven core overlap with Java records. In particular, all the classes
> > > generated from the `maven.mdo` file, but not only. In short term,
> > > migrating to records would remove the need to declare constructors,
> > > hashCode and equals methods, thus making classes simpler and reducing
> > > the risk of bugs. In medium term, "derived record creation" (currently
> > > in preview) could replace builders. That would be a massive
> > > simplification of record-like classes.
> >
> > As much as I would like to rip out Modello and chuck it into the
> > Mariana trench, I don't think that's likely to happen. Consequently
> > this is a non-starter. If you do manage to rip out and replace
> > Modello, then we can talk about record classes, but I don't want to
> > have both Modello and record classes, which is what would likely
> > happen if we tried this today.
> >
> > > Java 24+ (in a later Maven version) for class-file API. It would
> resolve
> > > at least some of the compatibility problems observed when new Java
> > > versions are released and Maven wants to analyse the byte code.
> >
> > This one is interesting. Unfortunately it's far too early to require
> > Java 24+ for users, which is what we'd need for this, since users
> > would need to run code that calls this API. I don't want to predict
> > exactly when this will be possible. However, it's multiple years away.
> > Most big dev shops are extremely slow to upgrade. 3 years ago when I
> > left Google, they had just finished a multi-year company wide
> > migration to Java 11. Meta isn't as big a Java shop, but they too were
> > using Java 11 at least through late 2024. They and others will
> > eventually get to Java 25, but that's years in the future.
> >
> > --
> > Elliotte Rusty Harold
> > elharo@ibiblio.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Jorge Solorzano <jo...@gmail.com>.
+1000 to Tamás comment,
On Sun, May 25, 2025 at 1:52 PM Tamás Cservenák <ta...@cservenak.net> wrote:
>
> Eliotte,
>
> While I sometimes find your hunting and fishing stories
> amusing, I also find them very tiresome.
>
> Maven is not a subcontractor or anything like that for any
> of the companies you keep talking about. Maven is not
> (contractually or in any other way) obliged to "deliver
> best experience" or even "support" to those companies
> you keep talking about.
>
> As it was said multiple times here, they are most probably
> happily using Maven3 and will keep using it.
>
> Please stop parroting these things _in relation_ to Maven 4.
>
> This is getting VERY demotivating, at least to me.
>
> I am here to have fun, and not to present some
> "corporate HOWTOs" I had experienced in my life
> (and very much hated). I understand your professional
> past had this and that taught you, but this is not your job.
> You are not better or worse by fixing or not fixing bugs
> here (or introducing them by doing other changes). This is
> an open source project, that does not account for
> spent hours, milestones and what not. Here
> the "do not touch until broken" is not in effect,
> as we do not aim for profit. There is no profit involved here.
> There is nothing "corporate" around here,
> this is supposed to be FUN.
>
> (in fact, there is: profit is when you have chance to
> sit with any of other maven-ers and have a beer with them,
> spend good time as you would with your friends,
> and NOT company coworkers. But this stands even
> for "online" chats, playing CSGO etc)
>
> So, I kindly ask you: Please stop.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Tamás Cservenák <ta...@cservenak.net>.
Eliotte,
While I sometimes find your hunting and fishing stories
amusing, I also find them very tiresome.
Maven is not a subcontractor or anything like that for any
of the companies you keep talking about. Maven is not
(contractually or in any other way) obliged to "deliver
best experience" or even "support" to those companies
you keep talking about.
As it was said multiple times here, they are most probably
happily using Maven3 and will keep using it.
Please stop parroting these things _in relation_ to Maven 4.
This is getting VERY demotivating, at least to me.
I am here to have fun, and not to present some
"corporate HOWTOs" I had experienced in my life
(and very much hated). I understand your professional
past had this and that taught you, but this is not your job.
You are not better or worse by fixing or not fixing bugs
here (or introducing them by doing other changes). This is
an open source project, that does not account for
spent hours, milestones and what not. Here
the "do not touch until broken" is not in effect,
as we do not aim for profit. There is no profit involved here.
There is nothing "corporate" around here,
this is supposed to be FUN.
(in fact, there is: profit is when you have chance to
sit with any of other maven-ers and have a beer with them,
spend good time as you would with your friends,
and NOT company coworkers. But this stands even
for "online" chats, playing CSGO etc)
So, I kindly ask you: Please stop.
On Sun, May 25, 2025 at 1:30 PM Elliotte Rusty Harold
<el...@ibiblio.org> wrote:
>
> On Sat, May 24, 2025 at 6:22 PM Martin Desruisseaux
> <ma...@geomatys.com> wrote:
>
> > Java 9+ for supporting JPMS. This is needed not only in some plugins
> > (compiler, javadoc, maybe surefire), but also in some places of Maven
> > core (class-path versus module-path, cache of module-info). Even if not
> > everyone is interested in JPMS, trying to enable JPMS while preserving
> > Java 8 compatibility (e.g. with reflection) would have been difficult.
>
> Can you be more specific? Is there some code we need to produce or
> compile that we cannot compile with Java 8? We are still trying to
> figure out how to lay out code for multi-module projects. That we
> haven't yet figured this out and haven't really needed to. suggests
> that maybe multi-module projects aren't all that important in the real
> world. JPMS has pretty much failed. It's not clear it was ever needed
> in the first place. That said, I would like to be able to support
> multi-module builds, but what exactly can't we do without requiring
> Java 11? There's plenty of Java 8 code that is fully compatible with
> JPMS. There's also some that isn't, typically due to split packages.
> However, those problems aren't resolved by upgrading the JDK. In fact,
> that's a reason a lot of projects avoid JPMS completely. All that
> said, if you can demonstrate in detail that Java 11 is required for
> Maven to build projects that use JPMS, and we have a plan for
> addressing everything else needed to support multi-module builds, then
> I would find that a compelling reason to require Java 11. It isn't
> easy though. I took a run at this myself during quarantine and got
> nowhere.
>
> > Java 16+ for starting the migration to records. Some data structures in
> > Maven core overlap with Java records. In particular, all the classes
> > generated from the `maven.mdo` file, but not only. In short term,
> > migrating to records would remove the need to declare constructors,
> > hashCode and equals methods, thus making classes simpler and reducing
> > the risk of bugs. In medium term, "derived record creation" (currently
> > in preview) could replace builders. That would be a massive
> > simplification of record-like classes.
>
> As much as I would like to rip out Modello and chuck it into the
> Mariana trench, I don't think that's likely to happen. Consequently
> this is a non-starter. If you do manage to rip out and replace
> Modello, then we can talk about record classes, but I don't want to
> have both Modello and record classes, which is what would likely
> happen if we tried this today.
>
> > Java 24+ (in a later Maven version) for class-file API. It would resolve
> > at least some of the compatibility problems observed when new Java
> > versions are released and Maven wants to analyse the byte code.
>
> This one is interesting. Unfortunately it's far too early to require
> Java 24+ for users, which is what we'd need for this, since users
> would need to run code that calls this API. I don't want to predict
> exactly when this will be possible. However, it's multiple years away.
> Most big dev shops are extremely slow to upgrade. 3 years ago when I
> left Google, they had just finished a multi-year company wide
> migration to Java 11. Meta isn't as big a Java shop, but they too were
> using Java 11 at least through late 2024. They and others will
> eventually get to Java 25, but that's years in the future.
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Sat, May 24, 2025 at 6:22 PM Martin Desruisseaux
<ma...@geomatys.com> wrote:
> Java 9+ for supporting JPMS. This is needed not only in some plugins
> (compiler, javadoc, maybe surefire), but also in some places of Maven
> core (class-path versus module-path, cache of module-info). Even if not
> everyone is interested in JPMS, trying to enable JPMS while preserving
> Java 8 compatibility (e.g. with reflection) would have been difficult.
Can you be more specific? Is there some code we need to produce or
compile that we cannot compile with Java 8? We are still trying to
figure out how to lay out code for multi-module projects. That we
haven't yet figured this out and haven't really needed to. suggests
that maybe multi-module projects aren't all that important in the real
world. JPMS has pretty much failed. It's not clear it was ever needed
in the first place. That said, I would like to be able to support
multi-module builds, but what exactly can't we do without requiring
Java 11? There's plenty of Java 8 code that is fully compatible with
JPMS. There's also some that isn't, typically due to split packages.
However, those problems aren't resolved by upgrading the JDK. In fact,
that's a reason a lot of projects avoid JPMS completely. All that
said, if you can demonstrate in detail that Java 11 is required for
Maven to build projects that use JPMS, and we have a plan for
addressing everything else needed to support multi-module builds, then
I would find that a compelling reason to require Java 11. It isn't
easy though. I took a run at this myself during quarantine and got
nowhere.
> Java 16+ for starting the migration to records. Some data structures in
> Maven core overlap with Java records. In particular, all the classes
> generated from the `maven.mdo` file, but not only. In short term,
> migrating to records would remove the need to declare constructors,
> hashCode and equals methods, thus making classes simpler and reducing
> the risk of bugs. In medium term, "derived record creation" (currently
> in preview) could replace builders. That would be a massive
> simplification of record-like classes.
As much as I would like to rip out Modello and chuck it into the
Mariana trench, I don't think that's likely to happen. Consequently
this is a non-starter. If you do manage to rip out and replace
Modello, then we can talk about record classes, but I don't want to
have both Modello and record classes, which is what would likely
happen if we tried this today.
> Java 24+ (in a later Maven version) for class-file API. It would resolve
> at least some of the compatibility problems observed when new Java
> versions are released and Maven wants to analyse the byte code.
This one is interesting. Unfortunately it's far too early to require
Java 24+ for users, which is what we'd need for this, since users
would need to run code that calls this API. I don't want to predict
exactly when this will be possible. However, it's multiple years away.
Most big dev shops are extremely slow to upgrade. 3 years ago when I
left Google, they had just finished a multi-year company wide
migration to Java 11. Meta isn't as big a Java shop, but they too were
using Java 11 at least through late 2024. They and others will
eventually get to Java 25, but that's years in the future.
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Hello all
Le 2025-05-24 à 15 h 33, Elliotte Rusty Harold a écrit :
> If you want to upgrade the minimum Java version, you need a better
> reason than that. I haven't yet heard a reason strong enough to
> convince me. Others have other opinions.
>
Java 9+ for supporting JPMS. This is needed not only in some plugins
(compiler, javadoc, maybe surefire), but also in some places of Maven
core (class-path versus module-path, cache of module-info). Even if not
everyone is interested in JPMS, trying to enable JPMS while preserving
Java 8 compatibility (e.g. with reflection) would have been difficult.
Java 16+ for starting the migration to records. Some data structures in
Maven core overlap with Java records. In particular, all the classes
generated from the `maven.mdo` file, but not only. In short term,
migrating to records would remove the need to declare constructors,
hashCode and equals methods, thus making classes simpler and reducing
the risk of bugs. In medium term, "derived record creation" (currently
in preview) could replace builders. That would be a massive
simplification of record-like classes.
Java 24+ (in a later Maven version) for class-file API. It would resolve
at least some of the compatibility problems observed when new Java
versions are released and Maven wants to analyse the byte code.
> I would much rather people invested their time into fixing Maven bugs
> and improving the health of the codebase rather than continuously
> migrating code from one Java version to the next.
>
There is two distinct tasks:
* Making sure that Maven is compatible with latest Java version. This
is the task that sometime requires work. This task must be done in
any cases.
* Upgrading the minimum Java version. Assuming that above task is
done, this task is not much more than changing the value of some
properties.
Upgrading the minimum Java version does not force us to migrate any
code. But we can start using new API that make some tasks easier, thus
saving time.
Martin
Re: [RESULT][VOTE] Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Sat, May 24, 2025 at 6:27 PM Manfred Moser <ma...@simpligility.ca> wrote:
> I also find it amazing that we have to justify and vote for upgrading.
> Why not the inverse ... we always upgrade by default and we do a vote on
> demand only. Then we decide for supporting old, outdated, and hence
> often insecure stuff (runtime, dependencies and so on) instead because
> ... well.. I don't know.
I call FUD. Maven is mostly in control of its own dependencies, and
those third party dependencies we do use generally are supported on
Java 8. Spotless (build time only) is the only notable exception I
can think of, and I'd be happy to ditch that. We don't run with
outdated dependencies or unsupported JDKs. When we have outdated
dependencies, it's because no one has pressed the Squash and Merge
button on a dependabot PR. It has nothing to do with Java versions.
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [RESULT][VOTE] Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Manfred Moser <ma...@simpligility.ca>.
As I mentioned in my earlier summary .. the majority of binding and
non-binding votes were for upgrading to 21. I still heard no one
bringing a good reason for ignoring a majority vote because we had a few
objections.
I also find it amazing that we have to justify and vote for upgrading.
Why not the inverse ... we always upgrade by default and we do a vote on
demand only. Then we decide for supporting old, outdated, and hence
often insecure stuff (runtime, dependencies and so on) instead because
... well.. I don't know.
In my opinion we should be upgrading to make the latest LTS a
requirement by default with new releases and have a vote to decide if we
want to support the LTS that is one older.
In any case .. for the current situation I strongly believe we should
upgrade to 21 as majority votes indicate. Maven 4 will be a modern and
new version of a great build and I am still baffled by some thinking it
should work with an old, outdated JDK.
Manfred
On 2025-05-24 10:52 a.m., Karl Heinz Marbaise wrote:
> Hi,
>
> greatly summarized.
>
> Thank you for that.
>
> Kind regards
> Karl Heinz Marbaise
>
>
> On 24.05.25 19:21, Michael Bien wrote:
>>
>> On 5/24/25 15:33, Elliotte Rusty Harold wrote:
>>> On Sat, May 24, 2025 at 1:16 PM Tamás Cservenák
>>> <ta...@cservenak.net> wrote:
>>>> ... aaand because some company/ies does/do that,
>>>> we as an open source project/forget need/must stick to it?
>>> The claim that we must move our JDK version forward because Java
>>> 8/11/17 is not supported is fallacious. It is based on a false
>>> premise.
>>>
>>> If you want to upgrade the minimum Java version, you need a better
>>> reason than that. I haven't yet heard a reason strong enough to
>>> convince me. Others have other opinions.
>>
>> I would be curious what the strategy would have been if maven 4 would
>> have decided to stay on JDK 8.
>>
>> Wait till 2030 and then throw maven away and build something new? Do
>> one big jump from 8 to 2x
>>
>> and hope the community would accept it? Hope that vendors would keep
>> supporting some slightly newer
>>
>> JDK versions beyond 2030 to get a few extra years out of it?
>>
>>
>> If vendors would not stop supporting JDKs, maven would have 7 JDK
>> versions to support in 2030 - this is
>>
>> quite a test matrix (not to mention the wasted resources).
>>
>>
>> Trying to keep the delta between 'min' and 'current' constant sounds
>> like the pragmatic approach for
>>
>> projects which plan to stick around. In fact many did and introduced
>> some easy to remember, forward
>>
>> looking rule like "our latest major version supports 2 LTS + current".
>>
>>
>> The crazy part about this discussion to me is that maven already has
>> a solution for this.
>>
>> Maven 3 exists, runs on JDK 8 and is supported as long as the
>> community wants to support it.
>>
>> Maven 4 could even do a RC more and be JDK 25+ without influencing
>> anyone on JDK 8.
>>
>>>> So basically, all we did so far was "waste of resources"
>>>> as Java 8 is there to stay, at least until 2030, right?
>>> IMHO, yes. I would much rather people invested their time into fixing
>>> Maven bugs and improving the health of the codebase rather than
>>> continuously migrating code from one Java version to the next.
>>
>> Bugfixes and refactoring are luckily not mutually exclusive and are
>> just regular project maintenance
>>
>> tasks.
>>
>> The cumulative time spent writing JDK version discussion mails is
>> probably already more than the
>>
>> review of a fictional global JDK 17->21 migration PR would take.
>> (that is another reason why many
>>
>> projects came up with an easy to remember min-version rule rather
>> than having to repeat this
>>
>> kind of threads every few years)
>>
>>
>> There is also no time pressure behind language level cleanups. They
>> can (and often should) happen
>>
>> incrementally, as needed, without disrupting any other tasks. The
>> point in time when the min
>>
>> requirements are bumped is only the starting point which unlocks more
>> cleanup options - the rest
>>
>> follows organically.
>>
>>
>>> That's
>>> life with a volunteer project though. Developers are going to do what
>>> they find fun rather than delivering user value.
>>
>> no fun allowed while producing value ;)
>>
>>
>> I could flip the argument and say that trying to reduce aspects which
>> are generally perceived as not-fun,
>>
>> probably creates value for everyone over the long term, including
>> users. Esp in open source projects
>>
>> which rely on motivated developers spending some of their free time
>> (or carefully negotiated work-time)
>>
>> helping to maintain it.
>>
>>
>> what lucky situation to be in when developers perceive modern APIs /
>> language idioms / cleaner code as
>>
>> more fun :)
>>
>>
>> (btw: is it ok to use vote threads for discussions?)
>>
>>
>> best regards,
>>
>> -mbien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [RESULT][VOTE] Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Karl Heinz Marbaise <kh...@gmx.de.INVALID>.
Hi,
greatly summarized.
Thank you for that.
Kind regards
Karl Heinz Marbaise
On 24.05.25 19:21, Michael Bien wrote:
>
> On 5/24/25 15:33, Elliotte Rusty Harold wrote:
>> On Sat, May 24, 2025 at 1:16 PM Tamás Cservenák <ta...@cservenak.net> wrote:
>>> ... aaand because some company/ies does/do that,
>>> we as an open source project/forget need/must stick to it?
>> The claim that we must move our JDK version forward because Java
>> 8/11/17 is not supported is fallacious. It is based on a false
>> premise.
>>
>> If you want to upgrade the minimum Java version, you need a better
>> reason than that. I haven't yet heard a reason strong enough to
>> convince me. Others have other opinions.
>
> I would be curious what the strategy would have been if maven 4 would have decided to stay on JDK 8.
>
> Wait till 2030 and then throw maven away and build something new? Do one big jump from 8 to 2x
>
> and hope the community would accept it? Hope that vendors would keep supporting some slightly newer
>
> JDK versions beyond 2030 to get a few extra years out of it?
>
>
> If vendors would not stop supporting JDKs, maven would have 7 JDK versions to support in 2030 - this is
>
> quite a test matrix (not to mention the wasted resources).
>
>
> Trying to keep the delta between 'min' and 'current' constant sounds like the pragmatic approach for
>
> projects which plan to stick around. In fact many did and introduced some easy to remember, forward
>
> looking rule like "our latest major version supports 2 LTS + current".
>
>
> The crazy part about this discussion to me is that maven already has a solution for this.
>
> Maven 3 exists, runs on JDK 8 and is supported as long as the community wants to support it.
>
> Maven 4 could even do a RC more and be JDK 25+ without influencing anyone on JDK 8.
>
>>> So basically, all we did so far was "waste of resources"
>>> as Java 8 is there to stay, at least until 2030, right?
>> IMHO, yes. I would much rather people invested their time into fixing
>> Maven bugs and improving the health of the codebase rather than
>> continuously migrating code from one Java version to the next.
>
> Bugfixes and refactoring are luckily not mutually exclusive and are just regular project maintenance
>
> tasks.
>
> The cumulative time spent writing JDK version discussion mails is probably already more than the
>
> review of a fictional global JDK 17->21 migration PR would take. (that is another reason why many
>
> projects came up with an easy to remember min-version rule rather than having to repeat this
>
> kind of threads every few years)
>
>
> There is also no time pressure behind language level cleanups. They can (and often should) happen
>
> incrementally, as needed, without disrupting any other tasks. The point in time when the min
>
> requirements are bumped is only the starting point which unlocks more cleanup options - the rest
>
> follows organically.
>
>
>> That's
>> life with a volunteer project though. Developers are going to do what
>> they find fun rather than delivering user value.
>
> no fun allowed while producing value ;)
>
>
> I could flip the argument and say that trying to reduce aspects which are generally perceived as not-fun,
>
> probably creates value for everyone over the long term, including users. Esp in open source projects
>
> which rely on motivated developers spending some of their free time (or carefully negotiated work-time)
>
> helping to maintain it.
>
>
> what lucky situation to be in when developers perceive modern APIs / language idioms / cleaner code as
>
> more fun :)
>
>
> (btw: is it ok to use vote threads for discussions?)
>
>
> best regards,
>
> -mbien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [RESULT][VOTE] Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Michael Bien <mb...@gmail.com>.
On 5/24/25 15:33, Elliotte Rusty Harold wrote:
> On Sat, May 24, 2025 at 1:16 PM Tamás Cservenák <ta...@cservenak.net> wrote:
>> ... aaand because some company/ies does/do that,
>> we as an open source project/forget need/must stick to it?
> The claim that we must move our JDK version forward because Java
> 8/11/17 is not supported is fallacious. It is based on a false
> premise.
>
> If you want to upgrade the minimum Java version, you need a better
> reason than that. I haven't yet heard a reason strong enough to
> convince me. Others have other opinions.
I would be curious what the strategy would have been if maven 4 would have decided to stay on JDK 8.
Wait till 2030 and then throw maven away and build something new? Do one big jump from 8 to 2x
and hope the community would accept it? Hope that vendors would keep supporting some slightly newer
JDK versions beyond 2030 to get a few extra years out of it?
If vendors would not stop supporting JDKs, maven would have 7 JDK versions to support in 2030 - this is
quite a test matrix (not to mention the wasted resources).
Trying to keep the delta between 'min' and 'current' constant sounds like the pragmatic approach for
projects which plan to stick around. In fact many did and introduced some easy to remember, forward
looking rule like "our latest major version supports 2 LTS + current".
The crazy part about this discussion to me is that maven already has a solution for this.
Maven 3 exists, runs on JDK 8 and is supported as long as the community wants to support it.
Maven 4 could even do a RC more and be JDK 25+ without influencing anyone on JDK 8.
>> So basically, all we did so far was "waste of resources"
>> as Java 8 is there to stay, at least until 2030, right?
> IMHO, yes. I would much rather people invested their time into fixing
> Maven bugs and improving the health of the codebase rather than
> continuously migrating code from one Java version to the next.
Bugfixes and refactoring are luckily not mutually exclusive and are just regular project maintenance
tasks.
The cumulative time spent writing JDK version discussion mails is probably already more than the
review of a fictional global JDK 17->21 migration PR would take. (that is another reason why many
projects came up with an easy to remember min-version rule rather than having to repeat this
kind of threads every few years)
There is also no time pressure behind language level cleanups. They can (and often should) happen
incrementally, as needed, without disrupting any other tasks. The point in time when the min
requirements are bumped is only the starting point which unlocks more cleanup options - the rest
follows organically.
> That's
> life with a volunteer project though. Developers are going to do what
> they find fun rather than delivering user value.
no fun allowed while producing value ;)
I could flip the argument and say that trying to reduce aspects which are generally perceived as not-fun,
probably creates value for everyone over the long term, including users. Esp in open source projects
which rely on motivated developers spending some of their free time (or carefully negotiated work-time)
helping to maintain it.
what lucky situation to be in when developers perceive modern APIs / language idioms / cleaner code as
more fun :)
(btw: is it ok to use vote threads for discussions?)
best regards,
-mbien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [RESULT][VOTE] Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Jorge Solorzano <jo...@gmail.com>.
On Sat, May 24, 2025, 15:34 Elliotte Rusty Harold <el...@ibiblio.org>
wrote:
> On Sat, May 24, 2025 at 1:16 PM Tamás Cservenák <ta...@cservenak.net>
> wrote:
> >
> > ... aaand because some company/ies does/do that,
> > we as an open source project/forget need/must stick to it?
>
> The claim that we must move our JDK version forward because Java
> 8/11/17 is not supported is fallacious. It is based on a false
> premise.
>
The claim that we must not move our JDK version forward because Java
8/11/17 is not supported is fallacious. It's based on a false premise.
>
> If you want to upgrade the minimum Java version, you need a better
> reason than that. I haven't yet heard a reason strong enough to
> convince me. Others have other opinions.
>
If you don't want to upgrade the minimum Java version, you don't need to
upgrade Maven and stick on Maven 3.9 forever. There are no strong enough
reasons to upgrade Java if you want to keep using an older, unsupported,
slower, and insecure Java version if you want.
> > So basically, all we did so far was "waste of resources"
> > as Java 8 is there to stay, at least until 2030, right?
>
> IMHO, yes. I would much rather people invested their time into fixing
> Maven bugs and improving the health of the codebase rather than
> continuously migrating code from one Java version to the next. That's
> life with a volunteer project though. Developers are going to do what
> they find fun rather than delivering user value.
--
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [RESULT][VOTE] Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Sat, May 24, 2025 at 1:16 PM Tamás Cservenák <ta...@cservenak.net> wrote:
>
> ... aaand because some company/ies does/do that,
> we as an open source project/forget need/must stick to it?
The claim that we must move our JDK version forward because Java
8/11/17 is not supported is fallacious. It is based on a false
premise.
If you want to upgrade the minimum Java version, you need a better
reason than that. I haven't yet heard a reason strong enough to
convince me. Others have other opinions.
> So basically, all we did so far was "waste of resources"
> as Java 8 is there to stay, at least until 2030, right?
IMHO, yes. I would much rather people invested their time into fixing
Maven bugs and improving the health of the codebase rather than
continuously migrating code from one Java version to the next. That's
life with a volunteer project though. Developers are going to do what
they find fun rather than delivering user value.
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [RESULT][VOTE] Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Tamás Cservenák <ta...@cservenak.net>.
... aaand because some company/ies does/do that,
we as an open source project/forget need/must stick to it?
So basically, all we did so far was "waste of resources"
as Java 8 is there to stay, at least until 2030, right?
Why did we bother at all!
On Sat, May 24, 2025 at 3:10 PM Elliotte Rusty Harold
<el...@ibiblio.org> wrote:
>
> On Fri, May 23, 2025 at 5:38 PM Benjamin Marwell <bm...@apache.org> wrote:
> >
> > Hey, I can totally understand the people voting -1 for the given reasons.
> > Even with Java 17 support ending in ~15 months FOR PERSONAL USE.
>
>
> This is **NOT** true, though people keep repeating this. Java 8, 11,
> and 17 will be supported for some time to come. Oracle might stop
> supporting them. Oracle != Java. For example, Amazon has commited "to
> provide performance enhancements and security updates at no cost until
> at least the specified date for the relevant release version (e.g.
> December 2030 for Corretto 8)." There are many other vendors.
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [RESULT][VOTE] Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Fri, May 23, 2025 at 5:38 PM Benjamin Marwell <bm...@apache.org> wrote:
>
> Hey, I can totally understand the people voting -1 for the given reasons.
> Even with Java 17 support ending in ~15 months FOR PERSONAL USE.
This is **NOT** true, though people keep repeating this. Java 8, 11,
and 17 will be supported for some time to come. Oracle might stop
supporting them. Oracle != Java. For example, Amazon has commited "to
provide performance enhancements and security updates at no cost until
at least the specified date for the relevant release version (e.g.
December 2030 for Corretto 8)." There are many other vendors.
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [RESULT][VOTE] Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Benjamin Marwell <bm...@apache.org>.
Hey, I can totally understand the people voting -1 for the given reasons.
Even with Java 17 support ending in ~15 months FOR PERSONAL USE.
There will be a loooooong tail of extended support for money.
Anyway, my suggestion:
Let's do Maven 4.0.0 with Java 17.
Wait for a 4.0.1, 4.1.0... and then with Maven 4.2.0 or 4.3.0 let's
look again into lifting the runtime requirement to Java 21.
By then, community support is about to end and most plugins will be
lifted to 17, which will give us a much tighter ecosystem.
"Aufgeschoben ist nicht aufgehoben" => "Postponed is not cancelled"
Does that work for you? Sounds like a reasonable common ground.
It is similar to what has been done with Maven 3, no?
- Ben
Am Mo., 12. Mai 2025 um 23:42 Uhr schrieb Henning Schmiedehausen
<he...@schmiedehausen.org.invalid>:
>
> As a case in point, I am slowly moving the plugins that I maintain (
> https://basepom.github.io/) to Java 17 and 21, even though these are Maven
> 3.x.x plugins. I will require projects that adopt those to use 17 or 21 to
> run the build. Which is fine, because I can still deliver Java 8 or Java 11
> compatible software even if building on a newer JDK.
>
> Java 17 is "end of public support" in ~ 15 months. By that time, two newer
> LTS versions (21 and 25) will be available. And 21 gives a path to use
> things like FFI which do not exist in 17.
>
> This decision seems to be too much on the conservative side. Anyone who
> does not want to upgrade Java will not upgrade to Maven 4 anyway.
>
> -h
>
>
>
> On Sat, May 10, 2025 at 1:17 PM Tamás Cservenák <ta...@cservenak.net> wrote:
>
> > Howdy,
> >
> > very same sentiment over here as well. I am very disappointed with the
> > outcome.
> >
> > So, I am curious about folks voting -1...
> >
> > Is one of them planning to go rogue and surprise us all by doing a
> > Maven 4 GA release soon? :D
> >
> > Thanks
> >
> > T
> >
> >
> >
> > On Sat, May 10, 2025 at 8:58 PM Mirko Friedenhagen
> > <mf...@gmx.de.invalid> wrote:
> > >
> > > I completely second Manfred here:
> > >
> > > - People who are willing to use Maven 4 soonish should be considered
> > fast movers. So I guess these are already using Java 21 anyways.
> > > - Going from Java 17 to 21 does not require major adaptions if any in
> > code in my experience.
> > > - New LTS Java 25 comes out this year, so even 21 will not be the shiny
> > new version.
> > >
> > > Mit freundlichen Grüßen
> > > Mirko Friedenhagen
> > > —
> > > Sent from my mobile
> > >
> > > > Am 04.05.2025 um 20:45 schrieb Manfred Moser <manfred@simpligility.ca
> > >:
> > > >
> > > > Hi all,
> > > >
> > > > I find this extremely disappointing and also confusing. A majority of
> > binding and non-binding votes opted FOR adopting Java 21. How can this be
> > justified with our procedures?
> > > >
> > > > Here are my arguments for adopting Java 21 that seems to have been
> > asked for although they are imho obvious.
> > > >
> > > > * Maven 4 will be a brand new release with many changes. An upgrade of
> > the required Java version is already included. Changing that from 17 to 21
> > does not have that much impact on users.
> > > >
> > > > * Java 21 is the latest current Java LTS release, and Java 25 as the
> > next LTS will be out in September .. that might even be before Maven 4
> > ships.
> > > >
> > > > * Java 21 has numerous improvements on top of 17 that making
> > programming with it better (and newer versions are even better).
> > > >
> > > > * Programmers will be less inclined to help a project that uses an old
> > Java version (17 is 3 years old.. ) and therefore prohibits them for using
> > modern programming styles and usage.
> > > >
> > > > * Performance of Java 21 is better and it is more suitable to run on
> > containers (which is common for CI and CD systems these days.
> > > >
> > > > * As a project overall we should strive to provide modern powerful
> > tooling and that also includes using modern runtime versions and taking
> > advantage of new features.
> > > >
> > > > * A later upgrade to Java 21 in in 4.1 for example seem to make sense
> > sense for a minor version update.
> > > >
> > > > * Holding us back to Java 17 means we can not start refactoring the
> > code to take advantage of features from 18, 19, 20, and 21.
> > > >
> > > > Beyond that I want to discount the "valid" arguments:
> > > >
> > > > * Procedurally there is nothing wrong with changing in the RC phase.
> > There is no rule about how long that phase is and how many RCs there should
> > be.
> > > >
> > > > * The new constraints on users only apply if they upgrade to Maven 4
> > .. which is completely optional.
> > > >
> > > > * Even people who voted with -1 said that they would like to upgrade
> > and that it would be nice, so what is really holding this back.
> > > >
> > > > I therefore ask for the conclusion to be reconsidered and following
> > our majority rules to adopt the raise to Java 21 as requirements for Maven
> > 4 before we release a final version.
> > > >
> > > > Manfred
> > > >
> > > >> On 2025-05-03 11:57 p.m., Matthias Bünger wrote:
> > > >> Morning everyone,
> > > >> first I would like to thank everybody who participated in the vote
> > [*1] about lifting the required Java version to 21 for Maven 4.0.0.
> > > >>
> > > >> The vote has ended with the following votes:
> > > >>
> > > >> --------------
> > > >> Binding votes:
> > > >>
> > > >> +1: Sylwester Lachiewicz, Karl Heinz Marbaise, Tamás Cservenák,
> > Benjamin Marwell, Arnaud Héritier, Tibor Digaňa
> > > >>
> > > >> -1: Michael Osipov, Maarten Mulders, Olivier Lamy, Slawomir
> > Jaranowski, Hervé Boutemy
> > > >>
> > > >>
> > > >> Non-binding votes:
> > > >>
> > > >> +1: Gary Gregory, Mateusz Gajewski, Mantas Gridinas, Rodrigo Bourbon,
> > Willker Gomes, Hans Aikema, Martin Desruisseaux, Torsten Heit, Sandra
> > Parsick, Dawid Law, Philipp Picej, John Neffenger, Jeremy Landis, Daniel B.
> > Widdis, Michael Bien, Gregorz Grzybek, Kévin Buntrock, Jorge Solorzano,
> > Mark Derricutt, Matthias Bünger, Basil Crow, Romain Manni-Bucau, Thomas
> > Sundberg, Anders Hammar, Piotr P. Karwasz, Niels Basjes, Enrico Olivelli
> > > >>
> > > >> -1: Elliotte Rusty Harold
> > > >>
> > > >> --------------
> > > >>
> > > >> 5 out of 11 binding votes are -1 with valid arguments, including that
> > there is no actual need to upgrade, that (it's too late, as ) we are
> > already in RC phase, and that it might put on new constraints to users. The
> > vote was (in line to the vote about lifting Maven 4 to Java 17) a
> > "procedural majority vote", meaing a simple majority of binding votes would
> > be enough to considered it to be passed. But due the high number of
> > negative votes and brought up arguments, I don't think we should ignore
> > them but take them into consideration for the benefit of the Maven
> > community. Therefore I call the vote to be non successful. We can
> > reevaluate in the future, including having a closer look at / discussion
> > about the benefits and constraints of raising the Java version.
> > > >>
> > > >>
> > > >> Wish you a happy sunday!
> > > >> Matthias
> > > >>
> > > >> [*1]:
> > https://lists.apache.org/thread/mjbx64vlbd346ov3l4wj6fy9vh8608vr
> > > >>
> > > >>
> > > >> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > >> For additional commands, e-mail: dev-help@maven.apache.org
> > > >>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [RESULT][VOTE] Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Henning Schmiedehausen <he...@schmiedehausen.org.INVALID>.
As a case in point, I am slowly moving the plugins that I maintain (
https://basepom.github.io/) to Java 17 and 21, even though these are Maven
3.x.x plugins. I will require projects that adopt those to use 17 or 21 to
run the build. Which is fine, because I can still deliver Java 8 or Java 11
compatible software even if building on a newer JDK.
Java 17 is "end of public support" in ~ 15 months. By that time, two newer
LTS versions (21 and 25) will be available. And 21 gives a path to use
things like FFI which do not exist in 17.
This decision seems to be too much on the conservative side. Anyone who
does not want to upgrade Java will not upgrade to Maven 4 anyway.
-h
On Sat, May 10, 2025 at 1:17 PM Tamás Cservenák <ta...@cservenak.net> wrote:
> Howdy,
>
> very same sentiment over here as well. I am very disappointed with the
> outcome.
>
> So, I am curious about folks voting -1...
>
> Is one of them planning to go rogue and surprise us all by doing a
> Maven 4 GA release soon? :D
>
> Thanks
>
> T
>
>
>
> On Sat, May 10, 2025 at 8:58 PM Mirko Friedenhagen
> <mf...@gmx.de.invalid> wrote:
> >
> > I completely second Manfred here:
> >
> > - People who are willing to use Maven 4 soonish should be considered
> fast movers. So I guess these are already using Java 21 anyways.
> > - Going from Java 17 to 21 does not require major adaptions if any in
> code in my experience.
> > - New LTS Java 25 comes out this year, so even 21 will not be the shiny
> new version.
> >
> > Mit freundlichen Grüßen
> > Mirko Friedenhagen
> > —
> > Sent from my mobile
> >
> > > Am 04.05.2025 um 20:45 schrieb Manfred Moser <manfred@simpligility.ca
> >:
> > >
> > > Hi all,
> > >
> > > I find this extremely disappointing and also confusing. A majority of
> binding and non-binding votes opted FOR adopting Java 21. How can this be
> justified with our procedures?
> > >
> > > Here are my arguments for adopting Java 21 that seems to have been
> asked for although they are imho obvious.
> > >
> > > * Maven 4 will be a brand new release with many changes. An upgrade of
> the required Java version is already included. Changing that from 17 to 21
> does not have that much impact on users.
> > >
> > > * Java 21 is the latest current Java LTS release, and Java 25 as the
> next LTS will be out in September .. that might even be before Maven 4
> ships.
> > >
> > > * Java 21 has numerous improvements on top of 17 that making
> programming with it better (and newer versions are even better).
> > >
> > > * Programmers will be less inclined to help a project that uses an old
> Java version (17 is 3 years old.. ) and therefore prohibits them for using
> modern programming styles and usage.
> > >
> > > * Performance of Java 21 is better and it is more suitable to run on
> containers (which is common for CI and CD systems these days.
> > >
> > > * As a project overall we should strive to provide modern powerful
> tooling and that also includes using modern runtime versions and taking
> advantage of new features.
> > >
> > > * A later upgrade to Java 21 in in 4.1 for example seem to make sense
> sense for a minor version update.
> > >
> > > * Holding us back to Java 17 means we can not start refactoring the
> code to take advantage of features from 18, 19, 20, and 21.
> > >
> > > Beyond that I want to discount the "valid" arguments:
> > >
> > > * Procedurally there is nothing wrong with changing in the RC phase.
> There is no rule about how long that phase is and how many RCs there should
> be.
> > >
> > > * The new constraints on users only apply if they upgrade to Maven 4
> .. which is completely optional.
> > >
> > > * Even people who voted with -1 said that they would like to upgrade
> and that it would be nice, so what is really holding this back.
> > >
> > > I therefore ask for the conclusion to be reconsidered and following
> our majority rules to adopt the raise to Java 21 as requirements for Maven
> 4 before we release a final version.
> > >
> > > Manfred
> > >
> > >> On 2025-05-03 11:57 p.m., Matthias Bünger wrote:
> > >> Morning everyone,
> > >> first I would like to thank everybody who participated in the vote
> [*1] about lifting the required Java version to 21 for Maven 4.0.0.
> > >>
> > >> The vote has ended with the following votes:
> > >>
> > >> --------------
> > >> Binding votes:
> > >>
> > >> +1: Sylwester Lachiewicz, Karl Heinz Marbaise, Tamás Cservenák,
> Benjamin Marwell, Arnaud Héritier, Tibor Digaňa
> > >>
> > >> -1: Michael Osipov, Maarten Mulders, Olivier Lamy, Slawomir
> Jaranowski, Hervé Boutemy
> > >>
> > >>
> > >> Non-binding votes:
> > >>
> > >> +1: Gary Gregory, Mateusz Gajewski, Mantas Gridinas, Rodrigo Bourbon,
> Willker Gomes, Hans Aikema, Martin Desruisseaux, Torsten Heit, Sandra
> Parsick, Dawid Law, Philipp Picej, John Neffenger, Jeremy Landis, Daniel B.
> Widdis, Michael Bien, Gregorz Grzybek, Kévin Buntrock, Jorge Solorzano,
> Mark Derricutt, Matthias Bünger, Basil Crow, Romain Manni-Bucau, Thomas
> Sundberg, Anders Hammar, Piotr P. Karwasz, Niels Basjes, Enrico Olivelli
> > >>
> > >> -1: Elliotte Rusty Harold
> > >>
> > >> --------------
> > >>
> > >> 5 out of 11 binding votes are -1 with valid arguments, including that
> there is no actual need to upgrade, that (it's too late, as ) we are
> already in RC phase, and that it might put on new constraints to users. The
> vote was (in line to the vote about lifting Maven 4 to Java 17) a
> "procedural majority vote", meaing a simple majority of binding votes would
> be enough to considered it to be passed. But due the high number of
> negative votes and brought up arguments, I don't think we should ignore
> them but take them into consideration for the benefit of the Maven
> community. Therefore I call the vote to be non successful. We can
> reevaluate in the future, including having a closer look at / discussion
> about the benefits and constraints of raising the Java version.
> > >>
> > >>
> > >> Wish you a happy sunday!
> > >> Matthias
> > >>
> > >> [*1]:
> https://lists.apache.org/thread/mjbx64vlbd346ov3l4wj6fy9vh8608vr
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> For additional commands, e-mail: dev-help@maven.apache.org
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [RESULT][VOTE] Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Tamás Cservenák <ta...@cservenak.net>.
Howdy,
very same sentiment over here as well. I am very disappointed with the outcome.
So, I am curious about folks voting -1...
Is one of them planning to go rogue and surprise us all by doing a
Maven 4 GA release soon? :D
Thanks
T
On Sat, May 10, 2025 at 8:58 PM Mirko Friedenhagen
<mf...@gmx.de.invalid> wrote:
>
> I completely second Manfred here:
>
> - People who are willing to use Maven 4 soonish should be considered fast movers. So I guess these are already using Java 21 anyways.
> - Going from Java 17 to 21 does not require major adaptions if any in code in my experience.
> - New LTS Java 25 comes out this year, so even 21 will not be the shiny new version.
>
> Mit freundlichen Grüßen
> Mirko Friedenhagen
> —
> Sent from my mobile
>
> > Am 04.05.2025 um 20:45 schrieb Manfred Moser <ma...@simpligility.ca>:
> >
> > Hi all,
> >
> > I find this extremely disappointing and also confusing. A majority of binding and non-binding votes opted FOR adopting Java 21. How can this be justified with our procedures?
> >
> > Here are my arguments for adopting Java 21 that seems to have been asked for although they are imho obvious.
> >
> > * Maven 4 will be a brand new release with many changes. An upgrade of the required Java version is already included. Changing that from 17 to 21 does not have that much impact on users.
> >
> > * Java 21 is the latest current Java LTS release, and Java 25 as the next LTS will be out in September .. that might even be before Maven 4 ships.
> >
> > * Java 21 has numerous improvements on top of 17 that making programming with it better (and newer versions are even better).
> >
> > * Programmers will be less inclined to help a project that uses an old Java version (17 is 3 years old.. ) and therefore prohibits them for using modern programming styles and usage.
> >
> > * Performance of Java 21 is better and it is more suitable to run on containers (which is common for CI and CD systems these days.
> >
> > * As a project overall we should strive to provide modern powerful tooling and that also includes using modern runtime versions and taking advantage of new features.
> >
> > * A later upgrade to Java 21 in in 4.1 for example seem to make sense sense for a minor version update.
> >
> > * Holding us back to Java 17 means we can not start refactoring the code to take advantage of features from 18, 19, 20, and 21.
> >
> > Beyond that I want to discount the "valid" arguments:
> >
> > * Procedurally there is nothing wrong with changing in the RC phase. There is no rule about how long that phase is and how many RCs there should be.
> >
> > * The new constraints on users only apply if they upgrade to Maven 4 .. which is completely optional.
> >
> > * Even people who voted with -1 said that they would like to upgrade and that it would be nice, so what is really holding this back.
> >
> > I therefore ask for the conclusion to be reconsidered and following our majority rules to adopt the raise to Java 21 as requirements for Maven 4 before we release a final version.
> >
> > Manfred
> >
> >> On 2025-05-03 11:57 p.m., Matthias Bünger wrote:
> >> Morning everyone,
> >> first I would like to thank everybody who participated in the vote [*1] about lifting the required Java version to 21 for Maven 4.0.0.
> >>
> >> The vote has ended with the following votes:
> >>
> >> --------------
> >> Binding votes:
> >>
> >> +1: Sylwester Lachiewicz, Karl Heinz Marbaise, Tamás Cservenák, Benjamin Marwell, Arnaud Héritier, Tibor Digaňa
> >>
> >> -1: Michael Osipov, Maarten Mulders, Olivier Lamy, Slawomir Jaranowski, Hervé Boutemy
> >>
> >>
> >> Non-binding votes:
> >>
> >> +1: Gary Gregory, Mateusz Gajewski, Mantas Gridinas, Rodrigo Bourbon, Willker Gomes, Hans Aikema, Martin Desruisseaux, Torsten Heit, Sandra Parsick, Dawid Law, Philipp Picej, John Neffenger, Jeremy Landis, Daniel B. Widdis, Michael Bien, Gregorz Grzybek, Kévin Buntrock, Jorge Solorzano, Mark Derricutt, Matthias Bünger, Basil Crow, Romain Manni-Bucau, Thomas Sundberg, Anders Hammar, Piotr P. Karwasz, Niels Basjes, Enrico Olivelli
> >>
> >> -1: Elliotte Rusty Harold
> >>
> >> --------------
> >>
> >> 5 out of 11 binding votes are -1 with valid arguments, including that there is no actual need to upgrade, that (it's too late, as ) we are already in RC phase, and that it might put on new constraints to users. The vote was (in line to the vote about lifting Maven 4 to Java 17) a "procedural majority vote", meaing a simple majority of binding votes would be enough to considered it to be passed. But due the high number of negative votes and brought up arguments, I don't think we should ignore them but take them into consideration for the benefit of the Maven community. Therefore I call the vote to be non successful. We can reevaluate in the future, including having a closer look at / discussion about the benefits and constraints of raising the Java version.
> >>
> >>
> >> Wish you a happy sunday!
> >> Matthias
> >>
> >> [*1]: https://lists.apache.org/thread/mjbx64vlbd346ov3l4wj6fy9vh8608vr
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [RESULT][VOTE] Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Mirko Friedenhagen <mf...@gmx.de.INVALID>.
I completely second Manfred here:
- People who are willing to use Maven 4 soonish should be considered fast movers. So I guess these are already using Java 21 anyways.
- Going from Java 17 to 21 does not require major adaptions if any in code in my experience.
- New LTS Java 25 comes out this year, so even 21 will not be the shiny new version.
Mit freundlichen Grüßen
Mirko Friedenhagen
—
Sent from my mobile
> Am 04.05.2025 um 20:45 schrieb Manfred Moser <ma...@simpligility.ca>:
>
> Hi all,
>
> I find this extremely disappointing and also confusing. A majority of binding and non-binding votes opted FOR adopting Java 21. How can this be justified with our procedures?
>
> Here are my arguments for adopting Java 21 that seems to have been asked for although they are imho obvious.
>
> * Maven 4 will be a brand new release with many changes. An upgrade of the required Java version is already included. Changing that from 17 to 21 does not have that much impact on users.
>
> * Java 21 is the latest current Java LTS release, and Java 25 as the next LTS will be out in September .. that might even be before Maven 4 ships.
>
> * Java 21 has numerous improvements on top of 17 that making programming with it better (and newer versions are even better).
>
> * Programmers will be less inclined to help a project that uses an old Java version (17 is 3 years old.. ) and therefore prohibits them for using modern programming styles and usage.
>
> * Performance of Java 21 is better and it is more suitable to run on containers (which is common for CI and CD systems these days.
>
> * As a project overall we should strive to provide modern powerful tooling and that also includes using modern runtime versions and taking advantage of new features.
>
> * A later upgrade to Java 21 in in 4.1 for example seem to make sense sense for a minor version update.
>
> * Holding us back to Java 17 means we can not start refactoring the code to take advantage of features from 18, 19, 20, and 21.
>
> Beyond that I want to discount the "valid" arguments:
>
> * Procedurally there is nothing wrong with changing in the RC phase. There is no rule about how long that phase is and how many RCs there should be.
>
> * The new constraints on users only apply if they upgrade to Maven 4 .. which is completely optional.
>
> * Even people who voted with -1 said that they would like to upgrade and that it would be nice, so what is really holding this back.
>
> I therefore ask for the conclusion to be reconsidered and following our majority rules to adopt the raise to Java 21 as requirements for Maven 4 before we release a final version.
>
> Manfred
>
>> On 2025-05-03 11:57 p.m., Matthias Bünger wrote:
>> Morning everyone,
>> first I would like to thank everybody who participated in the vote [*1] about lifting the required Java version to 21 for Maven 4.0.0.
>>
>> The vote has ended with the following votes:
>>
>> --------------
>> Binding votes:
>>
>> +1: Sylwester Lachiewicz, Karl Heinz Marbaise, Tamás Cservenák, Benjamin Marwell, Arnaud Héritier, Tibor Digaňa
>>
>> -1: Michael Osipov, Maarten Mulders, Olivier Lamy, Slawomir Jaranowski, Hervé Boutemy
>>
>>
>> Non-binding votes:
>>
>> +1: Gary Gregory, Mateusz Gajewski, Mantas Gridinas, Rodrigo Bourbon, Willker Gomes, Hans Aikema, Martin Desruisseaux, Torsten Heit, Sandra Parsick, Dawid Law, Philipp Picej, John Neffenger, Jeremy Landis, Daniel B. Widdis, Michael Bien, Gregorz Grzybek, Kévin Buntrock, Jorge Solorzano, Mark Derricutt, Matthias Bünger, Basil Crow, Romain Manni-Bucau, Thomas Sundberg, Anders Hammar, Piotr P. Karwasz, Niels Basjes, Enrico Olivelli
>>
>> -1: Elliotte Rusty Harold
>>
>> --------------
>>
>> 5 out of 11 binding votes are -1 with valid arguments, including that there is no actual need to upgrade, that (it's too late, as ) we are already in RC phase, and that it might put on new constraints to users. The vote was (in line to the vote about lifting Maven 4 to Java 17) a "procedural majority vote", meaing a simple majority of binding votes would be enough to considered it to be passed. But due the high number of negative votes and brought up arguments, I don't think we should ignore them but take them into consideration for the benefit of the Maven community. Therefore I call the vote to be non successful. We can reevaluate in the future, including having a closer look at / discussion about the benefits and constraints of raising the Java version.
>>
>>
>> Wish you a happy sunday!
>> Matthias
>>
>> [*1]: https://lists.apache.org/thread/mjbx64vlbd346ov3l4wj6fy9vh8608vr
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [RESULT][VOTE] Require Java 21 for Maven 4 (Rephrased Vote)
Posted by Manfred Moser <ma...@simpligility.ca>.
Hi all,
I find this extremely disappointing and also confusing. A majority of
binding and non-binding votes opted FOR adopting Java 21. How can this
be justified with our procedures?
Here are my arguments for adopting Java 21 that seems to have been asked
for although they are imho obvious.
* Maven 4 will be a brand new release with many changes. An upgrade of
the required Java version is already included. Changing that from 17 to
21 does not have that much impact on users.
* Java 21 is the latest current Java LTS release, and Java 25 as the
next LTS will be out in September .. that might even be before Maven 4
ships.
* Java 21 has numerous improvements on top of 17 that making programming
with it better (and newer versions are even better).
* Programmers will be less inclined to help a project that uses an old
Java version (17 is 3 years old.. ) and therefore prohibits them for
using modern programming styles and usage.
* Performance of Java 21 is better and it is more suitable to run on
containers (which is common for CI and CD systems these days.
* As a project overall we should strive to provide modern powerful
tooling and that also includes using modern runtime versions and taking
advantage of new features.
* A later upgrade to Java 21 in in 4.1 for example seem to make sense
sense for a minor version update.
* Holding us back to Java 17 means we can not start refactoring the code
to take advantage of features from 18, 19, 20, and 21.
Beyond that I want to discount the "valid" arguments:
* Procedurally there is nothing wrong with changing in the RC phase.
There is no rule about how long that phase is and how many RCs there
should be.
* The new constraints on users only apply if they upgrade to Maven 4 ..
which is completely optional.
* Even people who voted with -1 said that they would like to upgrade and
that it would be nice, so what is really holding this back.
I therefore ask for the conclusion to be reconsidered and following our
majority rules to adopt the raise to Java 21 as requirements for Maven 4
before we release a final version.
Manfred
On 2025-05-03 11:57 p.m., Matthias Bünger wrote:
> Morning everyone,
> first I would like to thank everybody who participated in the vote
> [*1] about lifting the required Java version to 21 for Maven 4.0.0.
>
> The vote has ended with the following votes:
>
> --------------
> Binding votes:
>
> +1: Sylwester Lachiewicz, Karl Heinz Marbaise, Tamás Cservenák,
> Benjamin Marwell, Arnaud Héritier, Tibor Digaňa
>
> -1: Michael Osipov, Maarten Mulders, Olivier Lamy, Slawomir
> Jaranowski, Hervé Boutemy
>
>
> Non-binding votes:
>
> +1: Gary Gregory, Mateusz Gajewski, Mantas Gridinas, Rodrigo Bourbon,
> Willker Gomes, Hans Aikema, Martin Desruisseaux, Torsten Heit, Sandra
> Parsick, Dawid Law, Philipp Picej, John Neffenger, Jeremy Landis,
> Daniel B. Widdis, Michael Bien, Gregorz Grzybek, Kévin Buntrock, Jorge
> Solorzano, Mark Derricutt, Matthias Bünger, Basil Crow, Romain
> Manni-Bucau, Thomas Sundberg, Anders Hammar, Piotr P. Karwasz, Niels
> Basjes, Enrico Olivelli
>
> -1: Elliotte Rusty Harold
>
> --------------
>
> 5 out of 11 binding votes are -1 with valid arguments, including that
> there is no actual need to upgrade, that (it's too late, as ) we are
> already in RC phase, and that it might put on new constraints to
> users. The vote was (in line to the vote about lifting Maven 4 to Java
> 17) a "procedural majority vote", meaing a simple majority of binding
> votes would be enough to considered it to be passed. But due the high
> number of negative votes and brought up arguments, I don't think we
> should ignore them but take them into consideration for the benefit of
> the Maven community. Therefore I call the vote to be non successful.
> We can reevaluate in the future, including having a closer look at /
> discussion about the benefits and constraints of raising the Java
> version.
>
>
> Wish you a happy sunday!
> Matthias
>
> [*1]: https://lists.apache.org/thread/mjbx64vlbd346ov3l4wj6fy9vh8608vr
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [RESULT][VOTE] Require Java 21 for Maven 4 (Rephrased Vote)
Posted by "Piotr P. Karwasz" <pi...@mailing.copernik.eu>.
Hi Matthias,
On 4.05.2025 08:57, Matthias Bünger wrote:
> But due the high number of negative votes and brought up arguments, I
> don't think we should ignore them but take them into consideration for
> the benefit of the Maven community. Therefore I call the vote to be
> non successful. We can reevaluate in the future, including having a
> closer look at / discussion about the benefits and constraints of
> raising the Java version.
While I admit that the arguments against increasing the baseline to JDK
21 are compelling, shouldn't we leave the decision of keeping JDK 17 as
baseline to the PMC members that voted +1? Due to the small difference,
each one of them can declare the vote unsuccessful by changing their vote.
Personally I was convinced by the arguments and would like to change by
(non-binding) vote to +0.
Piotr
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [RESULT][VOTE] Require Java 21 for Maven 4 (Rephrased Vote)
Posted by David Law <Da...@apconsult.de.INVALID>.
Hi Matthias,
well I think you made the right decision:
even though you counted my vote incorrectly (I voted -1, not +1).
My reasons for the -1 were:
- JDK.8 is a museum-piece & should be replaced
- JDK.17 has a whole load of useful features, many would not like to miss
- JDK.21 has a couple, but I can live without them & it's just too new
All the best,
DaveLaw
On 04/05/2025 08:57, Matthias Bünger wrote:
> Morning everyone,
> first I would like to thank everybody who participated in the vote
> [*1] about lifting the required Java version to 21 for Maven 4.0.0.
>
> The vote has ended with the following votes:
>
> --------------
> Binding votes:
>
> +1: Sylwester Lachiewicz, Karl Heinz Marbaise, Tamás Cservenák,
> Benjamin Marwell, Arnaud Héritier, Tibor Digaňa
>
> -1: Michael Osipov, Maarten Mulders, Olivier Lamy, Slawomir
> Jaranowski, Hervé Boutemy
>
>
> Non-binding votes:
>
> +1: Gary Gregory, Mateusz Gajewski, Mantas Gridinas, Rodrigo Bourbon,
> Willker Gomes, Hans Aikema, Martin Desruisseaux, Torsten Heit, Sandra
> Parsick, Dawid Law, Philipp Picej, John Neffenger, Jeremy Landis,
> Daniel B. Widdis, Michael Bien, Gregorz Grzybek, Kévin Buntrock, Jorge
> Solorzano, Mark Derricutt, Matthias Bünger, Basil Crow, Romain
> Manni-Bucau, Thomas Sundberg, Anders Hammar, Piotr P. Karwasz, Niels
> Basjes, Enrico Olivelli
>
> -1: Elliotte Rusty Harold
>
> --------------
>
> 5 out of 11 binding votes are -1 with valid arguments, including that
> there is no actual need to upgrade, that (it's too late, as ) we are
> already in RC phase, and that it might put on new constraints to
> users. The vote was (in line to the vote about lifting Maven 4 to Java
> 17) a "procedural majority vote", meaing a simple majority of binding
> votes would be enough to considered it to be passed. But due the high
> number of negative votes and brought up arguments, I don't think we
> should ignore them but take them into consideration for the benefit of
> the Maven community. Therefore I call the vote to be non successful.
> We can reevaluate in the future, including having a closer look at /
> discussion about the benefits and constraints of raising the Java
> version.
>
>
> Wish you a happy sunday!
> Matthias
>
> [*1]: https://lists.apache.org/thread/mjbx64vlbd346ov3l4wj6fy9vh8608vr
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org