Re: [VOTE] Require Java 21 for Maven 4 (Rephrased Vote)

[John Neffenger]

+1 (non-binding)

John

On 4/30/25 6:12 AM, Matthias Bünger wrote:
Therefore, I want to start the official vote to set the minimal Java 
bytecode target of Maven-Core 4 to 21, meaning Java 21 is required for 
Maven 4.



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

[DISCUSS] Publishing to Central + Maveniverse Njord

[Tamás Cservenák]

Howdy,

As we know, we have changes upcoming regarding publishing to central
(in short: oss/s01 are being sunset, Central Portal becomes the new
service; if unsure what am talking about, please google it up). Also,
while there were vendor and third-party plugins and solutions for
this, I am talking about the "vanilla Maven experience" here.

Maven aspect so far: all the "old" publishing services so far
(OSS/S01/RAO) were based on Sonatype Nx2 "tech", that provided support
for maven-deploy-plugin, basically allowing seamless use of these
services from within Maven (doing `mvn deploy` just worked) at the
cost of "pushing some buttons" as part of publishing workflow: you had
to close and release the staging repository that service created for
deploy, and the happy path was that after sync, we got artifacts
published to Central.

The new service is NOT maven-deploy-plugin friendly anymore. This
makes Maven, the project that invented Central, become unable to
publish to Central out of the box (again, "vanilla experience").

To continue, let's introduce some terminology to have all of us on the
same page:

* deploy(ing) - is what Maven always did (maven-deploy-plugin): it is
"uploading artifacts (one by one, request-wise) to some remote
location", by default it happens "interleaved as subproject lifecycle
runs" and it "edits" metadata as well. Later we introduced the "deploy
at end" feature, but nothing fundamentally changed here: the artifacts
are still deployed one-by-one, metadata handling is done by your
Maven, and to have your deployment complete, the last subproject of
the session must be deployed as well. Long time ago, when a remote
repository was imagined as a httpd+webdav, or today w/ MRM hosted
repository, this worked and works quite well.

* publish(ing) - Since 2010 things have changed: many tools already
use this term, and it is NOT the same thing as "deploying" or even
"deploying with a twist": is not even close to it. Publishing usually
has its own WORKFLOW, like explained above: get your payload there (in
some form), then do something (push some buttons), maybe spawn a vote
in between, and finally again do something (push some more buttons) to
finally get your artifacts somewhere. Publishing usually requires
handling your project output "as a whole", something not naturally
mapped onto the project itself. Finally, there is no (at least when
compared to deploy) much metadata requirement either, as "embedding"
your output to its final resting place is done by the vendor providing
the publishing service, as they have to, unless they want to end up
with corrupted metadata. Finally, "publishing" as described above is
not something Maven (3 or 4) is able to do today: so far all we had
was some variation of "deploy with a twist"-like hacks instead.

The new "publishing" involves two aspects:

* target - is WHERE you publish, to keep things simple, usually we
assume "target == Maven Central" but again, it could be anything (ie.
corporate MRM w/ staging used to get artifacts to some corporate
hosted repository). Targets also define the "requirements", like
mandatory and optional checksums, signatures and so on.

* service - is HOW you publish (basically a service implementing the
workflow mentioned above). Usually service implies target (ie. using
repository.apache.org you publish to Central) but does not have to.
Service is operated by some vendor, usually is not open source and
different services may require vastly different "ways" (protocols?) to
publish, as there are no standards defined in this area.

Today we have several services to publish, and they all end up on same
target, Central:
* repository.apache.org (apache-rao)
* oss.sonatype.org (sonatype-oss, soon to be sunset)
* s01.oss.sonatype.org (sonatype-s01, soon to be sunset)
* central.sonatype.com (sonatype-cp, the new "Central Portal" service)

In general, I'd propose the use of $vendor-$service naming to keep
things clear (and unique and future proof). Overuse of "central" is
just killing us, nor is it appropriate for any service, as it is the
target.

As said above, the sunset services are taking away the "native" Maven
deploy support. Moreover, Maven 4 is here to come, but we cannot leave
Maven 3 users alone either. In Maven 4 you can more easily hack up
some "deploy with a twist" solution, but this does not work for Maven
3 users.

Plus, I'd dare to say that publishing is something orthogonal to your
project. What if you want to publish to two places? Or what if you are
about to (or forced to) switch services you use for publishing? These
changes should be "simple" (as in light, simple to implement), but
instead, many times this imply quite a lot of changes on your project,
introducing new profiles, properties, plugins, maybe extensions, and
so on. Even if we consider the same target (Central), moving from one
service to another is not trivial. So far, Maven "got away" by using
(hence, changing) Nx2 staging endpoint in
distributionManage

Re: [VOTE] Require Java 21 for Maven 4

[Sylwester Lachiewicz]

+1 good move

śr., 30 kwi 2025, 14:44 użytkownik Matthias Bünger 
napisał:

> Hi everyone,
> over the last years we had several discussions about lifting the
> required Java version to run Maven from 8 to something higher. You can
> find them in the mail archive.
> In February 2024 we decided to lift it to 17 (see result: [1*]).
>
> An argument to pick 17 instead of 21 was to take the (at the point of
> voting) second last JDK for which vendors offer LTS (Note: LTS is
> important for companies).
> With Java 25 (next with LTS) coming in September and a final Maven 4.0.0
> on the horizon (no date yet), I think we should raise the minimum
> version once more and use Java 21, which will be the second last
> "LTS-JDK" in September. Doing this brings the benefit of avoid locking
> into an "already considered old" version (and of course the improvements
> of Java 18-21).
>
> In a chat with several PMC, committers and contributors nobody saw
> strong disadvantages on this. Therefore, I want to start the official
> vote to set the minimal Java bytecode target of Maven-Core 4 to 21,
> meaning Java 21 is required for Maven 4.
>
> This is a procedural majority vote [2*]:
> You can also vote with fractions and negative votes are not vetoes.
>
> The vote is open for at least 72 hours.
>
>
> Please also notice:
> * Maven 3 will stay at Java 8.
> * It's about the minimum Java version to run Maven 4, not to compile
> applications against. With Java 21 you can compile down to Java 8. For
> special JDK needs, also toolchain tools can be used.
>
>
> Have a sunny day everyone
>
> Matthias
>
> [1*]: https://lists.apache.org/thread/bfkvvjftrxypp06yj8zj919fcz0dt2zt
> [2*]: https://www.apache.org/foundation/voting.html
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Require Java 21 for Maven 4 (Rephrased Vote)

[Martin Desruisseaux]

+1 (non-binding)



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

[CANCELED] [VOTE] Require Java 21 for Maven 4

[Matthias Bünger]

Vote canceled to restart with rephrased vote thread (asked by Tamás)

Matthias

Am 30.04.2025 um 14:43 schrieb Matthias Bünger:

Hi everyone,
over the last years we had several discussions about lifting the 
required Java version to run Maven from 8 to something higher. You can 
find them in the mail archive.

In February 2024 we decided to lift it to 17 (see result: [1*]).

An argument to pick 17 instead of 21 was to take the (at the point of 
voting) second last JDK for which vendors offer LTS (Note: LTS is 
important for companies).
With Java 25 (next with LTS) coming in September and a final Maven 
4.0.0 on the horizon (no date yet), I think we should raise the 
minimum version once more and use Java 21, which will be the second 
last "LTS-JDK" in September. Doing this brings the benefit of avoid 
locking into an "already considered old" version (and of course the 
improvements of Java 18-21).


In a chat with several PMC, committers and contributors nobody saw 
strong disadvantages on this. Therefore, I want to start the official 
vote to set the minimal Java bytecode target of Maven-Core 4 to 21, 
meaning Java 21 is required for Maven 4.


This is a procedural majority vote [2*]:
You can also vote with fractions and negative votes are not vetoes.

The vote is open for at least 72 hours.


Please also notice:
* Maven 3 will stay at Java 8.
* It's about the minimum Java version to run Maven 4, not to compile 
applications against. With Java 21 you can compile down to Java 8. For 
special JDK needs, also toolchain tools can be used.



Have a sunny day everyone

Matthias

[1*]: https://lists.apache.org/thread/bfkvvjftrxypp06yj8zj919fcz0dt2zt
[2*]: https://www.apache.org/foundation/voting.html


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

Re: [VOTE] Require Java 21 for Maven 4 (Rephrased Vote)

[Karl Heinz Marbaise]

Hi,

+1 from me.

Kind regards
Karl Heinz Marbaise
On 30.04.25 15:12, Matthias Bünger wrote:

Hi everyone,
over the last years we had several discussions about lifting the 
required Java version to run Maven from 8 to something higher. You can 
find them in the mail archive.

In February 2024 we decided to lift it to 17 (see result: [1*]).

An argument to pick 17 instead of 21 was to take the (at the point of 
voting) second last JDK for which vendors offer LTS (Note: LTS is 
important for companies).
With Java 25 (next with LTS) coming in September and a final Maven 4.0.0 
on the horizon (no date yet), I think we should raise the minimum 
version once more and use Java 21, which will be the second last 
"LTS-JDK" in September. Doing this brings the benefit of avoid locking 
into an "already considered old" version (and of course the improvements 
of Java 18-21).


In a chat with several PMC, committers and contributors nobody saw 
strong disadvantages on this. Therefore, I want to start the official 
vote to set the minimal Java bytecode target of Maven-Core 4 to 21, 
meaning Java 21 is required for Maven 4.


This is a procedural majority vote [2*]. You can also vote with 
fractions and negative votes are not vetoes.
Please refrain from starting discussions in this thread, but do include 
a reasoning on downvotes and feel free to start a new discussion on the 
mailing list.


The vote is open for at least 72 hours.

Please also notice:
* Maven 3 will stay at Java 8.
* It's about the minimum Java version to run Maven 4, not to compile 
applications against. With Java 21 you can compile down to Java 8. For 
special JDK needs, also toolchain tools can be used.



Have a sunny day everyone

Matthias

[1*]: https://lists.apache.org/thread/bfkvvjftrxypp06yj8zj919fcz0dt2zt
[2*]: https://www.apache.org/foundation/voting.html





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

[VOTE] Require Java 21 for Maven 4 (Rephrased Vote)

[Matthias Bünger]

Hi everyone,
over the last years we had several discussions about lifting the 
required Java version to run Maven from 8 to something higher. You can 
find them in the mail archive.

In February 2024 we decided to lift it to 17 (see result: [1*]).

An argument to pick 17 instead of 21 was to take the (at the point of 
voting) second last JDK for which vendors offer LTS (Note: LTS is 
important for companies).
With Java 25 (next with LTS) coming in September and a final Maven 4.0.0 
on the horizon (no date yet), I think we should raise the minimum 
version once more and use Java 21, which will be the second last 
"LTS-JDK" in September. Doing this brings the benefit of avoid locking 
into an "already considered old" version (and of course the improvements 
of Java 18-21).


In a chat with several PMC, committers and contributors nobody saw 
strong disadvantages on this. Therefore, I want to start the official 
vote to set the minimal Java bytecode target of Maven-Core 4 to 21, 
meaning Java 21 is required for Maven 4.


This is a procedural majority vote [2*]. You can also vote with 
fractions and negative votes are not vetoes.
Please refrain from starting discussions in this thread, but do include 
a reasoning on downvotes and feel free to start a new discussion on the 
mailing list.


The vote is open for at least 72 hours.

Please also notice:
* Maven 3 will stay at Java 8.
* It's about the minimum Java version to run Maven 4, not to compile 
applications against. With Java 21 you can compile down to Java 8. For 
special JDK needs, also toolchain tools can be used.



Have a sunny day everyone

Matthias

[1*]: https://lists.apache.org/thread/bfkvvjftrxypp06yj8zj919fcz0dt2zt
[2*]: https://www.apache.org/foundation/voting.html


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

Re: [VOTE] Require Java 21 for Maven 4 (Rephrased Vote)

[Gary Gregory]

Non-binding +1

Gary

On Wed, Apr 30, 2025, 09:12 Matthias Bünger  wrote:

> Hi everyone,
> over the last years we had several discussions about lifting the
> required Java version to run Maven from 8 to something higher. You can
> find them in the mail archive.
> In February 2024 we decided to lift it to 17 (see result: [1*]).
>
> An argument to pick 17 instead of 21 was to take the (at the point of
> voting) second last JDK for which vendors offer LTS (Note: LTS is
> important for companies).
> With Java 25 (next with LTS) coming in September and a final Maven 4.0.0
> on the horizon (no date yet), I think we should raise the minimum
> version once more and use Java 21, which will be the second last
> "LTS-JDK" in September. Doing this brings the benefit of avoid locking
> into an "already considered old" version (and of course the improvements
> of Java 18-21).
>
> In a chat with several PMC, committers and contributors nobody saw
> strong disadvantages on this. Therefore, I want to start the official
> vote to set the minimal Java bytecode target of Maven-Core 4 to 21,
> meaning Java 21 is required for Maven 4.
>
> This is a procedural majority vote [2*]. You can also vote with
> fractions and negative votes are not vetoes.
> Please refrain from starting discussions in this thread, but do include
> a reasoning on downvotes and feel free to start a new discussion on the
> mailing list.
>
> The vote is open for at least 72 hours.
>
> Please also notice:
> * Maven 3 will stay at Java 8.
> * It's about the minimum Java version to run Maven 4, not to compile
> applications against. With Java 21 you can compile down to Java 8. For
> special JDK needs, also toolchain tools can be used.
>
>
> Have a sunny day everyone
>
> Matthias
>
> [1*]: https://lists.apache.org/thread/bfkvvjftrxypp06yj8zj919fcz0dt2zt
> [2*]: https://www.apache.org/foundation/voting.html
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Require Java 21 for Maven 4 (Rephrased Vote)

[Mateusz Gajewski]

Non-binding +1 :)

On Wed, Apr 30, 2025 at 3:16 PM Gary Gregory  wrote:

> Non-binding +1
>
> Gary
>
> On Wed, Apr 30, 2025, 09:12 Matthias Bünger  wrote:
>
> > Hi everyone,
> > over the last years we had several discussions about lifting the
> > required Java version to run Maven from 8 to something higher. You can
> > find them in the mail archive.
> > In February 2024 we decided to lift it to 17 (see result: [1*]).
> >
> > An argument to pick 17 instead of 21 was to take the (at the point of
> > voting) second last JDK for which vendors offer LTS (Note: LTS is
> > important for companies).
> > With Java 25 (next with LTS) coming in September and a final Maven 4.0.0
> > on the horizon (no date yet), I think we should raise the minimum
> > version once more and use Java 21, which will be the second last
> > "LTS-JDK" in September. Doing this brings the benefit of avoid locking
> > into an "already considered old" version (and of course the improvements
> > of Java 18-21).
> >
> > In a chat with several PMC, committers and contributors nobody saw
> > strong disadvantages on this. Therefore, I want to start the official
> > vote to set the minimal Java bytecode target of Maven-Core 4 to 21,
> > meaning Java 21 is required for Maven 4.
> >
> > This is a procedural majority vote [2*]. You can also vote with
> > fractions and negative votes are not vetoes.
> > Please refrain from starting discussions in this thread, but do include
> > a reasoning on downvotes and feel free to start a new discussion on the
> > mailing list.
> >
> > The vote is open for at least 72 hours.
> >
> > Please also notice:
> > * Maven 3 will stay at Java 8.
> > * It's about the minimum Java version to run Maven 4, not to compile
> > applications against. With Java 21 you can compile down to Java 8. For
> > special JDK needs, also toolchain tools can be used.
> >
> >
> > Have a sunny day everyone
> >
> > Matthias
> >
> > [1*]: https://lists.apache.org/thread/bfkvvjftrxypp06yj8zj919fcz0dt2zt
> > [2*]: https://www.apache.org/foundation/voting.html
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: [VOTE] Require Java 21 for Maven 4 (Rephrased Vote)

[Tamás Cservenák]

+1

Thanks
Tamas

On Wed, Apr 30, 2025 at 3:12 PM Matthias Bünger  wrote:
>
> Hi everyone,
> over the last years we had several discussions about lifting the
> required Java version to run Maven from 8 to something higher. You can
> find them in the mail archive.
> In February 2024 we decided to lift it to 17 (see result: [1*]).
>
> An argument to pick 17 instead of 21 was to take the (at the point of
> voting) second last JDK for which vendors offer LTS (Note: LTS is
> important for companies).
> With Java 25 (next with LTS) coming in September and a final Maven 4.0.0
> on the horizon (no date yet), I think we should raise the minimum
> version once more and use Java 21, which will be the second last
> "LTS-JDK" in September. Doing this brings the benefit of avoid locking
> into an "already considered old" version (and of course the improvements
> of Java 18-21).
>
> In a chat with several PMC, committers and contributors nobody saw
> strong disadvantages on this. Therefore, I want to start the official
> vote to set the minimal Java bytecode target of Maven-Core 4 to 21,
> meaning Java 21 is required for Maven 4.
>
> This is a procedural majority vote [2*]. You can also vote with
> fractions and negative votes are not vetoes.
> Please refrain from starting discussions in this thread, but do include
> a reasoning on downvotes and feel free to start a new discussion on the
> mailing list.
>
> The vote is open for at least 72 hours.
>
> Please also notice:
> * Maven 3 will stay at Java 8.
> * It's about the minimum Java version to run Maven 4, not to compile
> applications against. With Java 21 you can compile down to Java 8. For
> special JDK needs, also toolchain tools can be used.
>
>
> Have a sunny day everyone
>
> Matthias
>
> [1*]: https://lists.apache.org/thread/bfkvvjftrxypp06yj8zj919fcz0dt2zt
> [2*]: https://www.apache.org/foundation/voting.html
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

Re: [DISCUSS] Publishing to Central + Maveniverse Njord

[Benjamin Marwell]

I think we should also take a look at JReleaser.
It has been around quite a while, Andres is an excellent contact and maintainer.

Any reason why we should choose one of the two?

JReleaser moves the releasing process out of maven, which is a bit
sad. But it can be used as a plugin, too.
So maybe this would be a good solution, too?

- Ben

Am Mi., 30. Apr. 2025 um 17:18 Uhr schrieb Tamás Cservenák
:
>
> Howdy,
>
> As we know, we have changes upcoming regarding publishing to central
> (in short: oss/s01 are being sunset, Central Portal becomes the new
> service; if unsure what am talking about, please google it up). Also,
> while there were vendor and third-party plugins and solutions for
> this, I am talking about the "vanilla Maven experience" here.
>
> Maven aspect so far: all the "old" publishing services so far
> (OSS/S01/RAO) were based on Sonatype Nx2 "tech", that provided support
> for maven-deploy-plugin, basically allowing seamless use of these
> services from within Maven (doing `mvn deploy` just worked) at the
> cost of "pushing some buttons" as part of publishing workflow: you had
> to close and release the staging repository that service created for
> deploy, and the happy path was that after sync, we got artifacts
> published to Central.
>
> The new service is NOT maven-deploy-plugin friendly anymore. This
> makes Maven, the project that invented Central, become unable to
> publish to Central out of the box (again, "vanilla experience").
>
> To continue, let's introduce some terminology to have all of us on the
> same page:
>
> * deploy(ing) - is what Maven always did (maven-deploy-plugin): it is
> "uploading artifacts (one by one, request-wise) to some remote
> location", by default it happens "interleaved as subproject lifecycle
> runs" and it "edits" metadata as well. Later we introduced the "deploy
> at end" feature, but nothing fundamentally changed here: the artifacts
> are still deployed one-by-one, metadata handling is done by your
> Maven, and to have your deployment complete, the last subproject of
> the session must be deployed as well. Long time ago, when a remote
> repository was imagined as a httpd+webdav, or today w/ MRM hosted
> repository, this worked and works quite well.
>
> * publish(ing) - Since 2010 things have changed: many tools already
> use this term, and it is NOT the same thing as "deploying" or even
> "deploying with a twist": is not even close to it. Publishing usually
> has its own WORKFLOW, like explained above: get your payload there (in
> some form), then do something (push some buttons), maybe spawn a vote
> in between, and finally again do something (push some more buttons) to
> finally get your artifacts somewhere. Publishing usually requires
> handling your project output "as a whole", something not naturally
> mapped onto the project itself. Finally, there is no (at least when
> compared to deploy) much metadata requirement either, as "embedding"
> your output to its final resting place is done by the vendor providing
> the publishing service, as they have to, unless they want to end up
> with corrupted metadata. Finally, "publishing" as described above is
> not something Maven (3 or 4) is able to do today: so far all we had
> was some variation of "deploy with a twist"-like hacks instead.
>
> The new "publishing" involves two aspects:
>
> * target - is WHERE you publish, to keep things simple, usually we
> assume "target == Maven Central" but again, it could be anything (ie.
> corporate MRM w/ staging used to get artifacts to some corporate
> hosted repository). Targets also define the "requirements", like
> mandatory and optional checksums, signatures and so on.
>
> * service - is HOW you publish (basically a service implementing the
> workflow mentioned above). Usually service implies target (ie. using
> repository.apache.org you publish to Central) but does not have to.
> Service is operated by some vendor, usually is not open source and
> different services may require vastly different "ways" (protocols?) to
> publish, as there are no standards defined in this area.
>
> Today we have several services to publish, and they all end up on same
> target, Central:
> * repository.apache.org (apache-rao)
> * oss.sonatype.org (sonatype-oss, soon to be sunset)
> * s01.oss.sonatype.org (sonatype-s01, soon to be sunset)
> * central.sonatype.com (sonatype-cp, the new "Central Portal" service)
>
> In general, I'd propose the use of $vendor-$service naming to keep
> things clear (and unique and future proof). Overuse of "central" is
> just killing us, nor is it appropriate for any service, as it is the
> target.
>
> As said above, the sunset services are taking away the "native" Maven
> deploy support. Moreover, Maven 4 is here to come, but we cannot leave
> Maven 3 users alone either. In Maven 4 you can more easily hack up
> some "deploy with a twist" solution, but this does not work for Maven
> 3 users.
>
> Plus, I'd dare to say that publishing is something orth

Re: [VOTE] Require Java 21 for Maven 4 (Rephrased Vote)

[Benjamin Marwell]

+1 (binding)

Thanks!

Question to the -1 voters: Please do share a reason for downvotes. I
am eager to know why you think we should not update to Java 21.


Am Mi., 30. Apr. 2025 um 15:12 Uhr schrieb Matthias Bünger
:
>
> Hi everyone,
> over the last years we had several discussions about lifting the
> required Java version to run Maven from 8 to something higher. You can
> find them in the mail archive.
> In February 2024 we decided to lift it to 17 (see result: [1*]).
>
> An argument to pick 17 instead of 21 was to take the (at the point of
> voting) second last JDK for which vendors offer LTS (Note: LTS is
> important for companies).
> With Java 25 (next with LTS) coming in September and a final Maven 4.0.0
> on the horizon (no date yet), I think we should raise the minimum
> version once more and use Java 21, which will be the second last
> "LTS-JDK" in September. Doing this brings the benefit of avoid locking
> into an "already considered old" version (and of course the improvements
> of Java 18-21).
>
> In a chat with several PMC, committers and contributors nobody saw
> strong disadvantages on this. Therefore, I want to start the official
> vote to set the minimal Java bytecode target of Maven-Core 4 to 21,
> meaning Java 21 is required for Maven 4.
>
> This is a procedural majority vote [2*]. You can also vote with
> fractions and negative votes are not vetoes.
> Please refrain from starting discussions in this thread, but do include
> a reasoning on downvotes and feel free to start a new discussion on the
> mailing list.
>
> The vote is open for at least 72 hours.
>
> Please also notice:
> * Maven 3 will stay at Java 8.
> * It's about the minimum Java version to run Maven 4, not to compile
> applications against. With Java 21 you can compile down to Java 8. For
> special JDK needs, also toolchain tools can be used.
>
>
> Have a sunny day everyone
>
> Matthias
>
> [1*]: https://lists.apache.org/thread/bfkvvjftrxypp06yj8zj919fcz0dt2zt
> [2*]: https://www.apache.org/foundation/voting.html
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

Re: [DISCUSS] Publishing to Central + Maveniverse Njord

[Tamás Cservenák]

I think someone should reread the mail :)

Yes, many publishing tools have been out there for quite some time,
but they are "out of Maven" as you say, and usually they reinvent
their own universe as well.

But, just like MDK _did integrate_ JReleaser (did you check out MDK?),
nothing stops Njord to provide 5th publisher that is "Jreleaser
powered", aside of existing 4 ones (apache-rao, sonatype-oss,
sonatype-s01 and sonatype-cp). Also, if I remember correctly, I even
mentioned this to Andres on Maven Slack.

Still, just like in MDK times, I feel JReleaser is a bit "too much",
too heavyweight and doing way too much for this purpose (Maven
prepares all, no need for signing, hashing, assembling, checksumming,
assembling, etc).

On Wed, Apr 30, 2025 at 5:37 PM Benjamin Marwell  wrote:
>
> I think we should also take a look at JReleaser.
> It has been around quite a while, Andres is an excellent contact and 
> maintainer.
>
> Any reason why we should choose one of the two?
>
> JReleaser moves the releasing process out of maven, which is a bit
> sad. But it can be used as a plugin, too.
> So maybe this would be a good solution, too?
>
> - Ben
>
> Am Mi., 30. Apr. 2025 um 17:18 Uhr schrieb Tamás Cservenák
> :
> >
> > Howdy,
> >
> > As we know, we have changes upcoming regarding publishing to central
> > (in short: oss/s01 are being sunset, Central Portal becomes the new
> > service; if unsure what am talking about, please google it up). Also,
> > while there were vendor and third-party plugins and solutions for
> > this, I am talking about the "vanilla Maven experience" here.
> >
> > Maven aspect so far: all the "old" publishing services so far
> > (OSS/S01/RAO) were based on Sonatype Nx2 "tech", that provided support
> > for maven-deploy-plugin, basically allowing seamless use of these
> > services from within Maven (doing `mvn deploy` just worked) at the
> > cost of "pushing some buttons" as part of publishing workflow: you had
> > to close and release the staging repository that service created for
> > deploy, and the happy path was that after sync, we got artifacts
> > published to Central.
> >
> > The new service is NOT maven-deploy-plugin friendly anymore. This
> > makes Maven, the project that invented Central, become unable to
> > publish to Central out of the box (again, "vanilla experience").
> >
> > To continue, let's introduce some terminology to have all of us on the
> > same page:
> >
> > * deploy(ing) - is what Maven always did (maven-deploy-plugin): it is
> > "uploading artifacts (one by one, request-wise) to some remote
> > location", by default it happens "interleaved as subproject lifecycle
> > runs" and it "edits" metadata as well. Later we introduced the "deploy
> > at end" feature, but nothing fundamentally changed here: the artifacts
> > are still deployed one-by-one, metadata handling is done by your
> > Maven, and to have your deployment complete, the last subproject of
> > the session must be deployed as well. Long time ago, when a remote
> > repository was imagined as a httpd+webdav, or today w/ MRM hosted
> > repository, this worked and works quite well.
> >
> > * publish(ing) - Since 2010 things have changed: many tools already
> > use this term, and it is NOT the same thing as "deploying" or even
> > "deploying with a twist": is not even close to it. Publishing usually
> > has its own WORKFLOW, like explained above: get your payload there (in
> > some form), then do something (push some buttons), maybe spawn a vote
> > in between, and finally again do something (push some more buttons) to
> > finally get your artifacts somewhere. Publishing usually requires
> > handling your project output "as a whole", something not naturally
> > mapped onto the project itself. Finally, there is no (at least when
> > compared to deploy) much metadata requirement either, as "embedding"
> > your output to its final resting place is done by the vendor providing
> > the publishing service, as they have to, unless they want to end up
> > with corrupted metadata. Finally, "publishing" as described above is
> > not something Maven (3 or 4) is able to do today: so far all we had
> > was some variation of "deploy with a twist"-like hacks instead.
> >
> > The new "publishing" involves two aspects:
> >
> > * target - is WHERE you publish, to keep things simple, usually we
> > assume "target == Maven Central" but again, it could be anything (ie.
> > corporate MRM w/ staging used to get artifacts to some corporate
> > hosted repository). Targets also define the "requirements", like
> > mandatory and optional checksums, signatures and so on.
> >
> > * service - is HOW you publish (basically a service implementing the
> > workflow mentioned above). Usually service implies target (ie. using
> > repository.apache.org you publish to Central) but does not have to.
> > Service is operated by some vendor, usually is not open source and
> > different services may require vastly different "ways" (protocols?) to
> > publis

RE: [VOTE] Require Java 21 for Maven 4 (Rephrased Vote)

[Jeremy Landis]

Non-binding +1

- Jeremy

-Original Message-
From: Matthias Bünger 
Sent: Wednesday, April 30, 2025 9:13 AM
To: Maven Developers List 
Cc: us...@maven.apache.org
Subject: [VOTE] Require Java 21 for Maven 4 (Rephrased Vote)

Hi everyone,
over the last years we had several discussions about lifting the required Java 
version to run Maven from 8 to something higher. You can find them in the mail 
archive.
In February 2024 we decided to lift it to 17 (see result: [1*]).

An argument to pick 17 instead of 21 was to take the (at the point of
voting) second last JDK for which vendors offer LTS (Note: LTS is important for 
companies).
With Java 25 (next with LTS) coming in September and a final Maven 4.0.0 on the 
horizon (no date yet), I think we should raise the minimum version once more 
and use Java 21, which will be the second last "LTS-JDK" in September. Doing 
this brings the benefit of avoid locking into an "already considered old" 
version (and of course the improvements of Java 18-21).

In a chat with several PMC, committers and contributors nobody saw strong 
disadvantages on this. Therefore, I want to start the official vote to set the 
minimal Java bytecode target of Maven-Core 4 to 21, meaning Java 21 is required 
for Maven 4.

This is a procedural majority vote [2*]. You can also vote with fractions and 
negative votes are not vetoes.
Please refrain from starting discussions in this thread, but do include a 
reasoning on downvotes and feel free to start a new discussion on the mailing 
list.

The vote is open for at least 72 hours.

Please also notice:
* Maven 3 will stay at Java 8.
* It's about the minimum Java version to run Maven 4, not to compile 
applications against. With Java 21 you can compile down to Java 8. For special 
JDK needs, also toolchain tools can be used.


Have a sunny day everyone

Matthias

[1*]: https://lists.apache.org/thread/bfkvvjftrxypp06yj8zj919fcz0dt2zt
[2*]: https://www.apache.org/foundation/voting.html


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


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

Re: [VOTE] Require Java 21 for Maven 4 (Rephrased Vote)

[Michael Bien]

+1 (not binding)

best regards,
michael


On 4/30/25 15:12, Matthias Bünger wrote:
> Hi everyone,
> over the last years we had several discussions about lifting the required 
> Java version to run Maven from 8 to something higher. You can find them in 
> the mail archive.
> In February 2024 we decided to lift it to 17 (see result: [1*]).
>
> An argument to pick 17 instead of 21 was to take the (at the point of voting) 
> second last JDK for which vendors offer LTS (Note: LTS is important for 
> companies).
> With Java 25 (next with LTS) coming in September and a final Maven 4.0.0 on 
> the horizon (no date yet), I think we should raise the minimum version once 
> more and use Java 21, which will be the second last "LTS-JDK" in September. 
> Doing this brings the benefit of avoid locking into an "already considered 
> old" version (and of course the improvements of Java 18-21).
>
> In a chat with several PMC, committers and contributors nobody saw strong 
> disadvantages on this. Therefore, I want to start the official vote to set 
> the minimal Java bytecode target of Maven-Core 4 to 21, meaning Java 21 is 
> required for Maven 4.
>
> This is a procedural majority vote [2*]. You can also vote with fractions and 
> negative votes are not vetoes.
> Please refrain from starting discussions in this thread, but do include a 
> reasoning on downvotes and feel free to start a new discussion on the mailing 
> list.
>
> The vote is open for at least 72 hours.
>
> Please also notice:
> * Maven 3 will stay at Java 8.
> * It's about the minimum Java version to run Maven 4, not to compile 
> applications against. With Java 21 you can compile down to Java 8. For 
> special JDK needs, also toolchain tools can be used.
>
>
> Have a sunny day everyone
>
> Matthias
>
> [1*]: https://lists.apache.org/thread/bfkvvjftrxypp06yj8zj919fcz0dt2zt
> [2*]: https://www.apache.org/foundation/voting.html
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>


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

Re: [VOTE] Require Java 21 for Maven 4 (Rephrased Vote)

[Elliotte Rusty Harold]

-1

On Wed, Apr 30, 2025 at 1:12 PM Matthias Bünger  wrote:
>
> Hi everyone,
> over the last years we had several discussions about lifting the
> required Java version to run Maven from 8 to something higher. You can
> find them in the mail archive.
> In February 2024 we decided to lift it to 17 (see result: [1*]).
>
> An argument to pick 17 instead of 21 was to take the (at the point of
> voting) second last JDK for which vendors offer LTS (Note: LTS is
> important for companies).
> With Java 25 (next with LTS) coming in September and a final Maven 4.0.0
> on the horizon (no date yet), I think we should raise the minimum
> version once more and use Java 21, which will be the second last
> "LTS-JDK" in September. Doing this brings the benefit of avoid locking
> into an "already considered old" version (and of course the improvements
> of Java 18-21).
>
> In a chat with several PMC, committers and contributors nobody saw
> strong disadvantages on this. Therefore, I want to start the official
> vote to set the minimal Java bytecode target of Maven-Core 4 to 21,
> meaning Java 21 is required for Maven 4.
>
> This is a procedural majority vote [2*]. You can also vote with
> fractions and negative votes are not vetoes.
> Please refrain from starting discussions in this thread, but do include
> a reasoning on downvotes and feel free to start a new discussion on the
> mailing list.
>
> The vote is open for at least 72 hours.
>
> Please also notice:
> * Maven 3 will stay at Java 8.
> * It's about the minimum Java version to run Maven 4, not to compile
> applications against. With Java 21 you can compile down to Java 8. For
> special JDK needs, also toolchain tools can be used.
>
>
> Have a sunny day everyone
>
> Matthias
>
> [1*]: https://lists.apache.org/thread/bfkvvjftrxypp06yj8zj919fcz0dt2zt
> [2*]: https://www.apache.org/foundation/voting.html
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>


-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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

Re: [VOTE] Require Java 21 for Maven 4 (Rephrased Vote)

[Arnaud Héritier]

+1

Arnaud Héritier
GitHub/ASF/... : aheritier


On Wed, Apr 30, 2025 at 15:12 Matthias Bünger  wrote:

> Hi everyone,
> over the last years we had several discussions about lifting the
> required Java version to run Maven from 8 to something higher. You can
> find them in the mail archive.
> In February 2024 we decided to lift it to 17 (see result: [1*]).
>
> An argument to pick 17 instead of 21 was to take the (at the point of
> voting) second last JDK for which vendors offer LTS (Note: LTS is
> important for companies).
> With Java 25 (next with LTS) coming in September and a final Maven 4.0.0
> on the horizon (no date yet), I think we should raise the minimum
> version once more and use Java 21, which will be the second last
> "LTS-JDK" in September. Doing this brings the benefit of avoid locking
> into an "already considered old" version (and of course the improvements
> of Java 18-21).
>
> In a chat with several PMC, committers and contributors nobody saw
> strong disadvantages on this. Therefore, I want to start the official
> vote to set the minimal Java bytecode target of Maven-Core 4 to 21,
> meaning Java 21 is required for Maven 4.
>
> This is a procedural majority vote [2*]. You can also vote with
> fractions and negative votes are not vetoes.
> Please refrain from starting discussions in this thread, but do include
> a reasoning on downvotes and feel free to start a new discussion on the
> mailing list.
>
> The vote is open for at least 72 hours.
>
> Please also notice:
> * Maven 3 will stay at Java 8.
> * It's about the minimum Java version to run Maven 4, not to compile
> applications against. With Java 21 you can compile down to Java 8. For
> special JDK needs, also toolchain tools can be used.
>
>
> Have a sunny day everyone
>
> Matthias
>
> [1*]: https://lists.apache.org/thread/bfkvvjftrxypp06yj8zj919fcz0dt2zt
> [2*]: https://www.apache.org/foundation/voting.html
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Fwd: [VOTE] Require Java 21 for Maven 4 (Rephrased Vote)

[Matthias Bünger]

forwarded for public visibility



 Weitergeleitete Nachricht 
Betreff:Re: [VOTE] Require Java 21 for Maven 4 (Rephrased Vote)
Datum:  Wed, 30 Apr 2025 16:02:21 +0200
Von:David Law 
An: Matthias Bünger 



-1

Regards,
Dave


On 30/04/2025 15:12, Matthias Bünger wrote:

Hi everyone,
over the last years we had several discussions about lifting the 
required Java version to run Maven from 8 to something higher. You can 
find them in the mail archive.

In February 2024 we decided to lift it to 17 (see result: [1*]).

An argument to pick 17 instead of 21 was to take the (at the point of 
voting) second last JDK for which vendors offer LTS (Note: LTS is 
important for companies).
With Java 25 (next with LTS) coming in September and a final Maven 
4.0.0 on the horizon (no date yet), I think we should raise the 
minimum version once more and use Java 21, which will be the second 
last "LTS-JDK" in September. Doing this brings the benefit of avoid 
locking into an "already considered old" version (and of course the 
improvements of Java 18-21).


In a chat with several PMC, committers and contributors nobody saw 
strong disadvantages on this. Therefore, I want to start the official 
vote to set the minimal Java bytecode target of Maven-Core 4 to 21, 
meaning Java 21 is required for Maven 4.


This is a procedural majority vote [2*]. You can also vote with 
fractions and negative votes are not vetoes.
Please refrain from starting discussions in this thread, but do 
include a reasoning on downvotes and feel free to start a new 
discussion on the mailing list.


The vote is open for at least 72 hours.

Please also notice:
* Maven 3 will stay at Java 8.
* It's about the minimum Java version to run Maven 4, not to compile 
applications against. With Java 21 you can compile down to Java 8. For 
special JDK needs, also toolchain tools can be used.



Have a sunny day everyone

Matthias

[1*]: https://lists.apache.org/thread/bfkvvjftrxypp06yj8zj919fcz0dt2zt
[2*]: https://www.apache.org/foundation/voting.html


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

Re: [DISCUSS] Publishing to Central + Maveniverse Njord

[Tamás Cservenák]

Jeremy,

Just to be clear, you are not in the "vanilla" space, as you are using a
vendor plugin/extension, right?

On Wed, Apr 30, 2025, 18:26 Jeremy Landis  wrote:

> FYI regarding deploy plugin I wanted to point out from personal experience
> on the migration.
>
> maven deploy plugin still is used for snapshots per central documentation
> and I've been doing so for a few weeks now.
>
> Here is an existing action that is deploying to new central and still same
> deploy
> https://github.com/hazendaz/javabean-tester/blob/master/.github/workflows/sonatype.yaml
>
> The snapshot repository remains but as follows
>
> 
> central
> https://central.sonatype.com/repository/maven-snapshots/
> 
> 
>
> Yes, the release one is gone and instead central-publishing-maven-plugin
> is used instead.  One problem I ran into was with cyclonedx.  Because on a
> physical release, the deploy plugin is taken over by the central publishing
> extension and cyclonedx relies on deploy, this flag was necessary
> `false` for cyclonedx to deploy during
> release.
>
> Outside of that, to enable snapshot usage, it requires toggling it on in
> the new central.
>
> I've not seen any other concerns in that regard post migration.  I've
> migrated 11 group ids over and going through everything to ensure things
> are working as expected.
>
> - Jeremy
>
>
> -Original Message-
> From: Tamás Cservenák 
> Sent: Wednesday, April 30, 2025 11:52 AM
> To: Maven Developers List 
> Subject: Re: [DISCUSS] Publishing to Central + Maveniverse Njord
>
> I think someone should reread the mail :)
>
> Yes, many publishing tools have been out there for quite some time, but
> they are "out of Maven" as you say, and usually they reinvent their own
> universe as well.
>
> But, just like MDK _did integrate_ JReleaser (did you check out MDK?),
> nothing stops Njord to provide 5th publisher that is "Jreleaser powered",
> aside of existing 4 ones (apache-rao, sonatype-oss,
> sonatype-s01 and sonatype-cp). Also, if I remember correctly, I even
> mentioned this to Andres on Maven Slack.
>
> Still, just like in MDK times, I feel JReleaser is a bit "too much", too
> heavyweight and doing way too much for this purpose (Maven prepares all, no
> need for signing, hashing, assembling, checksumming, assembling, etc).
>
> On Wed, Apr 30, 2025 at 5:37 PM Benjamin Marwell 
> wrote:
> >
> > I think we should also take a look at JReleaser.
> > It has been around quite a while, Andres is an excellent contact and
> maintainer.
> >
> > Any reason why we should choose one of the two?
> >
> > JReleaser moves the releasing process out of maven, which is a bit
> > sad. But it can be used as a plugin, too.
> > So maybe this would be a good solution, too?
> >
> > - Ben
> >
> > Am Mi., 30. Apr. 2025 um 17:18 Uhr schrieb Tamás Cservenák
> > :
> > >
> > > Howdy,
> > >
> > > As we know, we have changes upcoming regarding publishing to central
> > > (in short: oss/s01 are being sunset, Central Portal becomes the new
> > > service; if unsure what am talking about, please google it up).
> > > Also, while there were vendor and third-party plugins and solutions
> > > for this, I am talking about the "vanilla Maven experience" here.
> > >
> > > Maven aspect so far: all the "old" publishing services so far
> > > (OSS/S01/RAO) were based on Sonatype Nx2 "tech", that provided
> > > support for maven-deploy-plugin, basically allowing seamless use of
> > > these services from within Maven (doing `mvn deploy` just worked) at
> > > the cost of "pushing some buttons" as part of publishing workflow:
> > > you had to close and release the staging repository that service
> > > created for deploy, and the happy path was that after sync, we got
> > > artifacts published to Central.
> > >
> > > The new service is NOT maven-deploy-plugin friendly anymore. This
> > > makes Maven, the project that invented Central, become unable to
> > > publish to Central out of the box (again, "vanilla experience").
> > >
> > > To continue, let's introduce some terminology to have all of us on
> > > the same page:
> > >
> > > * deploy(ing) - is what Maven always did (maven-deploy-plugin): it
> > > is "uploading artifacts (one by one, request-wise) to some remote
> > > location", by default it happens "interleaved as subproject
> > > lifecycle runs" and it "edits" metadata as well. Later we introduced
> > > the "deploy at end" feature, but nothing fundamentally changed here:
> > > the artifacts are still deployed one-by-one, metadata handling is
> > > done by your Maven, and to have your deployment complete, the last
> > > subproject of the session must be deployed as well. Long time ago,
> > > when a remote repository was imagined as a httpd+webdav, or today w/
> > > MRM hosted repository, this worked and works quite well.
> > >
> > > * publish(ing) - Since 2010 things have changed: many tools already
> > > use this term, and it is NOT the same thing as "deploying" or even
> > > "deploy

RE: [DISCUSS] Publishing to Central + Maveniverse Njord

[Jeremy Landis]

FYI regarding deploy plugin I wanted to point out from personal experience on 
the migration.

maven deploy plugin still is used for snapshots per central documentation and 
I've been doing so for a few weeks now.

Here is an existing action that is deploying to new central and still same 
deploy 
https://github.com/hazendaz/javabean-tester/blob/master/.github/workflows/sonatype.yaml

The snapshot repository remains but as follows


central
https://central.sonatype.com/repository/maven-snapshots/


Yes, the release one is gone and instead central-publishing-maven-plugin is 
used instead.  One problem I ran into was with cyclonedx.  Because on a 
physical release, the deploy plugin is taken over by the central publishing 
extension and cyclonedx relies on deploy, this flag was necessary 
`false` for cyclonedx to deploy during 
release.

Outside of that, to enable snapshot usage, it requires toggling it on in the 
new central.

I've not seen any other concerns in that regard post migration.  I've migrated 
11 group ids over and going through everything to ensure things are working as 
expected.

- Jeremy


-Original Message-
From: Tamás Cservenák  
Sent: Wednesday, April 30, 2025 11:52 AM
To: Maven Developers List 
Subject: Re: [DISCUSS] Publishing to Central + Maveniverse Njord

I think someone should reread the mail :)

Yes, many publishing tools have been out there for quite some time, but they 
are "out of Maven" as you say, and usually they reinvent their own universe as 
well.

But, just like MDK _did integrate_ JReleaser (did you check out MDK?), nothing 
stops Njord to provide 5th publisher that is "Jreleaser powered", aside of 
existing 4 ones (apache-rao, sonatype-oss,
sonatype-s01 and sonatype-cp). Also, if I remember correctly, I even mentioned 
this to Andres on Maven Slack.

Still, just like in MDK times, I feel JReleaser is a bit "too much", too 
heavyweight and doing way too much for this purpose (Maven prepares all, no 
need for signing, hashing, assembling, checksumming, assembling, etc).

On Wed, Apr 30, 2025 at 5:37 PM Benjamin Marwell  wrote:
>
> I think we should also take a look at JReleaser.
> It has been around quite a while, Andres is an excellent contact and 
> maintainer.
>
> Any reason why we should choose one of the two?
>
> JReleaser moves the releasing process out of maven, which is a bit 
> sad. But it can be used as a plugin, too.
> So maybe this would be a good solution, too?
>
> - Ben
>
> Am Mi., 30. Apr. 2025 um 17:18 Uhr schrieb Tamás Cservenák
> :
> >
> > Howdy,
> >
> > As we know, we have changes upcoming regarding publishing to central 
> > (in short: oss/s01 are being sunset, Central Portal becomes the new 
> > service; if unsure what am talking about, please google it up). 
> > Also, while there were vendor and third-party plugins and solutions 
> > for this, I am talking about the "vanilla Maven experience" here.
> >
> > Maven aspect so far: all the "old" publishing services so far
> > (OSS/S01/RAO) were based on Sonatype Nx2 "tech", that provided 
> > support for maven-deploy-plugin, basically allowing seamless use of 
> > these services from within Maven (doing `mvn deploy` just worked) at 
> > the cost of "pushing some buttons" as part of publishing workflow: 
> > you had to close and release the staging repository that service 
> > created for deploy, and the happy path was that after sync, we got 
> > artifacts published to Central.
> >
> > The new service is NOT maven-deploy-plugin friendly anymore. This 
> > makes Maven, the project that invented Central, become unable to 
> > publish to Central out of the box (again, "vanilla experience").
> >
> > To continue, let's introduce some terminology to have all of us on 
> > the same page:
> >
> > * deploy(ing) - is what Maven always did (maven-deploy-plugin): it 
> > is "uploading artifacts (one by one, request-wise) to some remote 
> > location", by default it happens "interleaved as subproject 
> > lifecycle runs" and it "edits" metadata as well. Later we introduced 
> > the "deploy at end" feature, but nothing fundamentally changed here: 
> > the artifacts are still deployed one-by-one, metadata handling is 
> > done by your Maven, and to have your deployment complete, the last 
> > subproject of the session must be deployed as well. Long time ago, 
> > when a remote repository was imagined as a httpd+webdav, or today w/ 
> > MRM hosted repository, this worked and works quite well.
> >
> > * publish(ing) - Since 2010 things have changed: many tools already 
> > use this term, and it is NOT the same thing as "deploying" or even 
> > "deploying with a twist": is not even close to it. Publishing 
> > usually has its own WORKFLOW, like explained above: get your payload 
> > there (in some form), then do something (push some buttons), maybe 
> > spawn a vote in between, and finally again do something (push some 
> > more buttons) to finally get your artifacts somewher

Re: [DISCUSS] Publishing to Central + Maveniverse Njord

[Jeremy Landis]

For snapshots, its vanilla.  I'm pretty sure that support was only recently 
added.  It's not using their plugin in that case.  I do find that confusing to 
users and their docs were slightly unclear.

Sent from my Verizon, Samsung Galaxy smartphone
Get Outlook for Android

From: Tamás Cservenák 
Sent: Wednesday, April 30, 2025 2:01:18 PM
To: Maven Developers List 
Subject: Re: [DISCUSS] Publishing to Central + Maveniverse Njord

Jeremy,

Just to be clear, you are not in the "vanilla" space, as you are using a
vendor plugin/extension, right?

On Wed, Apr 30, 2025, 18:26 Jeremy Landis  wrote:

> FYI regarding deploy plugin I wanted to point out from personal experience
> on the migration.
>
> maven deploy plugin still is used for snapshots per central documentation
> and I've been doing so for a few weeks now.
>
> Here is an existing action that is deploying to new central and still same
> deploy
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhazendaz%2Fjavabean-tester%2Fblob%2Fmaster%2F.github%2Fworkflows%2Fsonatype.yaml&data=05%7C02%7C%7Cc99efe5ea5924f9bdb5908dd88112bda%7C84df9e7fe9f640afb435%7C1%7C0%7C638816329514972273%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=lbXcndp7jToT%2B7cmYA7DDl%2Fo9bNAqfRls1lHPNrGlUM%3D&reserved=0
>
> The snapshot repository remains but as follows
>
> 
> central
> 
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcentral.sonatype.com%2Frepository%2Fmaven-snapshots%2F&data=05%7C02%7C%7Cc99efe5ea5924f9bdb5908dd88112bda%7C84df9e7fe9f640afb435%7C1%7C0%7C638816329514993840%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=dhJ0BBeqeW5itBQdvxOGVeiGwtRV9QgHd56tcvqh4OI%3D&reserved=0
> 
> 
>
> Yes, the release one is gone and instead central-publishing-maven-plugin
> is used instead.  One problem I ran into was with cyclonedx.  Because on a
> physical release, the deploy plugin is taken over by the central publishing
> extension and cyclonedx relies on deploy, this flag was necessary
> `false` for cyclonedx to deploy during
> release.
>
> Outside of that, to enable snapshot usage, it requires toggling it on in
> the new central.
>
> I've not seen any other concerns in that regard post migration.  I've
> migrated 11 group ids over and going through everything to ensure things
> are working as expected.
>
> - Jeremy
>
>
> -Original Message-
> From: Tamás Cservenák 
> Sent: Wednesday, April 30, 2025 11:52 AM
> To: Maven Developers List 
> Subject: Re: [DISCUSS] Publishing to Central + Maveniverse Njord
>
> I think someone should reread the mail :)
>
> Yes, many publishing tools have been out there for quite some time, but
> they are "out of Maven" as you say, and usually they reinvent their own
> universe as well.
>
> But, just like MDK _did integrate_ JReleaser (did you check out MDK?),
> nothing stops Njord to provide 5th publisher that is "Jreleaser powered",
> aside of existing 4 ones (apache-rao, sonatype-oss,
> sonatype-s01 and sonatype-cp). Also, if I remember correctly, I even
> mentioned this to Andres on Maven Slack.
>
> Still, just like in MDK times, I feel JReleaser is a bit "too much", too
> heavyweight and doing way too much for this purpose (Maven prepares all, no
> need for signing, hashing, assembling, checksumming, assembling, etc).
>
> On Wed, Apr 30, 2025 at 5:37 PM Benjamin Marwell 
> wrote:
> >
> > I think we should also take a look at JReleaser.
> > It has been around quite a while, Andres is an excellent contact and
> maintainer.
> >
> > Any reason why we should choose one of the two?
> >
> > JReleaser moves the releasing process out of maven, which is a bit
> > sad. But it can be used as a plugin, too.
> > So maybe this would be a good solution, too?
> >
> > - Ben
> >
> > Am Mi., 30. Apr. 2025 um 17:18 Uhr schrieb Tamás Cservenák
> > :
> > >
> > > Howdy,
> > >
> > > As we know, we have changes upcoming regarding publishing to central
> > > (in short: oss/s01 are being sunset, Central Portal becomes the new
> > > service; if unsure what am talking about, please google it up).
> > > Also, while there were vendor and third-party plugins and solutions
> > > for this, I am talking about the "vanilla Maven experience" here.
> > >
> > > Maven aspect so far: all the "old" publishing services so far
> > > (OSS/S01/RAO) were based on Sonatype Nx2 "tech", that provided
> > > support for maven-deploy-plugin, basically allowing seamless use of
> > > these services from within Maven (doing `mvn deploy` just worked) at
> > > the cost of "pushing some buttons" as part of publishing workflow:
> > > you had to close and release the staging reposi

Re: [VOTE] Require Java 21 for Maven 4

[Elliotte Rusty Harold]

-1

On Wed, Apr 30, 2025 at 12:45 PM Matthias Bünger  wrote:
>
> Hi everyone,
> over the last years we had several discussions about lifting the
> required Java version to run Maven from 8 to something higher. You can
> find them in the mail archive.
> In February 2024 we decided to lift it to 17 (see result: [1*]).
>
> An argument to pick 17 instead of 21 was to take the (at the point of
> voting) second last JDK for which vendors offer LTS (Note: LTS is
> important for companies).
> With Java 25 (next with LTS) coming in September and a final Maven 4.0.0
> on the horizon (no date yet), I think we should raise the minimum
> version once more and use Java 21, which will be the second last
> "LTS-JDK" in September. Doing this brings the benefit of avoid locking
> into an "already considered old" version (and of course the improvements
> of Java 18-21).
>
> In a chat with several PMC, committers and contributors nobody saw
> strong disadvantages on this. Therefore, I want to start the official
> vote to set the minimal Java bytecode target of Maven-Core 4 to 21,
> meaning Java 21 is required for Maven 4.
>
> This is a procedural majority vote [2*]:
> You can also vote with fractions and negative votes are not vetoes.
>
> The vote is open for at least 72 hours.
>
>
> Please also notice:
> * Maven 3 will stay at Java 8.
> * It's about the minimum Java version to run Maven 4, not to compile
> applications against. With Java 21 you can compile down to Java 8. For
> special JDK needs, also toolchain tools can be used.
>
>
> Have a sunny day everyone
>
> Matthias
>
> [1*]: https://lists.apache.org/thread/bfkvvjftrxypp06yj8zj919fcz0dt2zt
> [2*]: https://www.apache.org/foundation/voting.html
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>


-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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

Re: [VOTE] Require Java 21 for Maven 4

[Tamás Cservenák]

Howdy,

Matthias, you explained why to switch (why to vote +1).

But could you reformulate your VOTE thread and ask those voting -1 to
EXPLAIN why they voted in such a manner?

Thanks
T

On Wed, Apr 30, 2025 at 2:44 PM Matthias Bünger  wrote:
>
> Hi everyone,
> over the last years we had several discussions about lifting the
> required Java version to run Maven from 8 to something higher. You can
> find them in the mail archive.
> In February 2024 we decided to lift it to 17 (see result: [1*]).
>
> An argument to pick 17 instead of 21 was to take the (at the point of
> voting) second last JDK for which vendors offer LTS (Note: LTS is
> important for companies).
> With Java 25 (next with LTS) coming in September and a final Maven 4.0.0
> on the horizon (no date yet), I think we should raise the minimum
> version once more and use Java 21, which will be the second last
> "LTS-JDK" in September. Doing this brings the benefit of avoid locking
> into an "already considered old" version (and of course the improvements
> of Java 18-21).
>
> In a chat with several PMC, committers and contributors nobody saw
> strong disadvantages on this. Therefore, I want to start the official
> vote to set the minimal Java bytecode target of Maven-Core 4 to 21,
> meaning Java 21 is required for Maven 4.
>
> This is a procedural majority vote [2*]:
> You can also vote with fractions and negative votes are not vetoes.
>
> The vote is open for at least 72 hours.
>
>
> Please also notice:
> * Maven 3 will stay at Java 8.
> * It's about the minimum Java version to run Maven 4, not to compile
> applications against. With Java 21 you can compile down to Java 8. For
> special JDK needs, also toolchain tools can be used.
>
>
> Have a sunny day everyone
>
> Matthias
>
> [1*]: https://lists.apache.org/thread/bfkvvjftrxypp06yj8zj919fcz0dt2zt
> [2*]: https://www.apache.org/foundation/voting.html
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>

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

[VOTE] Require Java 21 for Maven 4

[Matthias Bünger]

Hi everyone,
over the last years we had several discussions about lifting the 
required Java version to run Maven from 8 to something higher. You can 
find them in the mail archive.

In February 2024 we decided to lift it to 17 (see result: [1*]).

An argument to pick 17 instead of 21 was to take the (at the point of 
voting) second last JDK for which vendors offer LTS (Note: LTS is 
important for companies).
With Java 25 (next with LTS) coming in September and a final Maven 4.0.0 
on the horizon (no date yet), I think we should raise the minimum 
version once more and use Java 21, which will be the second last 
"LTS-JDK" in September. Doing this brings the benefit of avoid locking 
into an "already considered old" version (and of course the improvements 
of Java 18-21).


In a chat with several PMC, committers and contributors nobody saw 
strong disadvantages on this. Therefore, I want to start the official 
vote to set the minimal Java bytecode target of Maven-Core 4 to 21, 
meaning Java 21 is required for Maven 4.


This is a procedural majority vote [2*]:
You can also vote with fractions and negative votes are not vetoes.

The vote is open for at least 72 hours.


Please also notice:
* Maven 3 will stay at Java 8.
* It's about the minimum Java version to run Maven 4, not to compile 
applications against. With Java 21 you can compile down to Java 8. For 
special JDK needs, also toolchain tools can be used.



Have a sunny day everyone

Matthias

[1*]: https://lists.apache.org/thread/bfkvvjftrxypp06yj8zj919fcz0dt2zt
[2*]: https://www.apache.org/foundation/voting.html


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

Re: [HEADS UP] Maven 3.9.10 release

[Guillaume Nodet]

The only way is to add the --enable-native-access=ALL-UNNAMED option in the
shell scripts afaik.  We've already added it in master.
Note that this option is not available in older JDK which are still
supported by Maven 3.9.


Guillaume Nodet



Le jeu. 1 mai 2025 à 05:19, Mark Derricutt  a écrit :

> Tamás, Guillaume -
>
> I note when running 3.9.9 under Java 24, I see:
>
> WARNING: A restricted method in java.lang.System has been called
> WARNING: java.lang.System::load has been called by
> org.fusesource.jansi.internal.JansiLoader in an unnamed module
> (file:/Users/amrk/.sdkman/candidates/maven/current/lib/jansi-2.4.1.jar)
> WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for
> callers in this module
> WARNING: Restricted methods will be blocked in a future release unless
> native access is enabled
>
> I also see that jansi:2.4.2 has been released (although not appearing in
> the Changelog yet):
>
> org.fusesource.jansi:jansi:2.4.2   29 Apr 2025 at
> 18:27 (NZST)
>
> Although looking at
> https://github.com/fusesource/jansi/compare/jansi-2.4.1...jansi-2.4.2 it
> doesn’t look like anything here will help with this.
>
> Not sure if there’s a ticket already for this (I may have raised one awhile
> ago?) - is there any quick win/fix to hide/remove those warnings we could
> get in a 3.9.10 release?
>
> Mark
>
> --
> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
> Porcupine Tree
>
>
> On 28 Apr 2025 at 11:58:34 PM, Tamás Cservenák 
> wrote:
>
> > Howdy,
> >
> > quickly scanned some recent MNG JIRAs, and I think these would be good
> > candidates as well:
> >
> > - https://issues.apache.org/jira/browse/MNG-8685 (limited mode, maybe
> > only GHA along the lines of original PR?)
> > - https://issues.apache.org/jira/browse/MNG-8663 (ASM update, it might
> > happen already in 3.9.x) - but along with the sisu and guice switch to
> > asm-less (non shaded) versions
> > - https://issues.apache.org/jira/browse/MNG-8623 -- this is more
> > "infra", make ITs use Mimir for caching just like master
> > - https://issues.apache.org/jira/browse/MNG-8638 -- not backporting,
> > but warning only? Also, IMO warning ONLY if values left uninterpolated
> >
> > will report with more
> >
> > On Fri, Apr 25, 2025 at 10:56 AM Tamás Cservenák 
> > wrote:
> >
> >
> > Hej,
> >
> >
> > Will take a peek and I think there is more to (both resolver and mvn3) it
> > next week
> >
> >
> > T
> >
> >
> > On Thu, Apr 24, 2025, 23:31 Slawomir Jaranowski 
> > wrote:
> >
> > >
> >
> > > Hi,
> >
> > >
> >
> > > I would like to release Maven 3.9.10
> >
> > >
> >
> > > We have planned issues:
> >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.10
> >
> > >
> >
> > > I also would like to release resolver 1.9.23
> >
> > > with issues:
> >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.23
> >
> > >
> >
> > > I will work on it, I hope the release can be done in the next two -
> > three weeks.
> >
> > > Any help as usual is appreciated.
> >
> > >
> >
> > >
> >
> > > --
> >
> > > Sławomir Jaranowski
> >
> > >
> >
> > > -
> >
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: [HEADS UP] Maven 3.9.10 release

[Mark Derricutt]

 All good, I noticed the version of Guava used reports the same.  I build
myself a local 3.9.10 build and do some tests as well.


Mark

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


On 1 May 2025 at 4:21:57 PM, Guillaume Nodet  wrote:

> The only way is to add the --enable-native-access=ALL-UNNAMED option in the
> shell scripts afaik.  We've already added it in master.
> Note that this option is not available in older JDK which are still
> supported by Maven 3.9.
>
> 
> Guillaume Nodet
>
>
>
> Le jeu. 1 mai 2025 à 05:19, Mark Derricutt  a écrit :
>
> Tamás, Guillaume -
>
>
> I note when running 3.9.9 under Java 24, I see:
>
>
> WARNING: A restricted method in java.lang.System has been called
>
> WARNING: java.lang.System::load has been called by
>
> org.fusesource.jansi.internal.JansiLoader in an unnamed module
>
> (file:/Users/amrk/.sdkman/candidates/maven/current/lib/jansi-2.4.1.jar)
>
> WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for
>
> callers in this module
>
> WARNING: Restricted methods will be blocked in a future release unless
>
> native access is enabled
>
>
> I also see that jansi:2.4.2 has been released (although not appearing in
>
> the Changelog yet):
>
>
> org.fusesource.jansi:jansi:2.4.2   29 Apr 2025 at
>
> 18:27 (NZST)
>
>
> Although looking at
>
> https://github.com/fusesource/jansi/compare/jansi-2.4.1...jansi-2.4.2 it
>
> doesn’t look like anything here will help with this.
>
>
> Not sure if there’s a ticket already for this (I may have raised one awhile
>
> ago?) - is there any quick win/fix to hide/remove those warnings we could
>
> get in a 3.9.10 release?
>
>
> Mark
>
>
> --
>
> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
>
> Porcupine Tree
>
>
>
> On 28 Apr 2025 at 11:58:34 PM, Tamás Cservenák 
>
> wrote:
>
>
> > Howdy,
>
> >
>
> > quickly scanned some recent MNG JIRAs, and I think these would be good
>
> > candidates as well:
>
> >
>
> > - https://issues.apache.org/jira/browse/MNG-8685 (limited mode, maybe
>
> > only GHA along the lines of original PR?)
>
> > - https://issues.apache.org/jira/browse/MNG-8663 (ASM update, it might
>
> > happen already in 3.9.x) - but along with the sisu and guice switch to
>
> > asm-less (non shaded) versions
>
> > - https://issues.apache.org/jira/browse/MNG-8623 -- this is more
>
> > "infra", make ITs use Mimir for caching just like master
>
> > - https://issues.apache.org/jira/browse/MNG-8638 -- not backporting,
>
> > but warning only? Also, IMO warning ONLY if values left uninterpolated
>
> >
>
> > will report with more
>
> >
>
> > On Fri, Apr 25, 2025 at 10:56 AM Tamás Cservenák 
>
> > wrote:
>
> >
>
> >
>
> > Hej,
>
> >
>
> >
>
> > Will take a peek and I think there is more to (both resolver and mvn3) it
>
> > next week
>
> >
>
> >
>
> > T
>
> >
>
> >
>
> > On Thu, Apr 24, 2025, 23:31 Slawomir Jaranowski 
>
> > wrote:
>
> >
>
> > >
>
> >
>
> > > Hi,
>
> >
>
> > >
>
> >
>
> > > I would like to release Maven 3.9.10
>
> >
>
> > >
>
> >
>
> > > We have planned issues:
>
> >
>
> > >
>
> >
>
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.10
>
> >
>
> > >
>
> >
>
> > > I also would like to release resolver 1.9.23
>
> >
>
> > > with issues:
>
> >
>
> > >
>
> >
>
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.23
>
> >
>
> > >
>
> >
>
> > > I will work on it, I hope the release can be done in the next two -
>
> > three weeks.
>
> >
>
> > > Any help as usual is appreciated.
>
> >
>
> > >
>
> >
>
> > >
>
> >
>
> > > --
>
> >
>
> > > Sławomir Jaranowski
>
> >
>
> > >
>
> >
>
> > > -
>
> >
>
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> >
>
> > > For additional commands, e-mail: dev-h...@maven.apache.org
>
> >
>
> > >
>
> >
>
> >
>
> > -
>
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
> >
>
> >
>
>
>

Re: [HEADS UP] Maven 3.9.10 release

[Gary Gregory]

Could MAVEN_ARGS or MAVEN_OPTS be used for this?

Gary

On Thu, May 1, 2025 at 12:22 AM Guillaume Nodet  wrote:
>
> The only way is to add the --enable-native-access=ALL-UNNAMED option in the
> shell scripts afaik.  We've already added it in master.
> Note that this option is not available in older JDK which are still
> supported by Maven 3.9.
>
> 
> Guillaume Nodet
>
>
>
> Le jeu. 1 mai 2025 à 05:19, Mark Derricutt  a écrit :
>
> > Tamás, Guillaume -
> >
> > I note when running 3.9.9 under Java 24, I see:
> >
> > WARNING: A restricted method in java.lang.System has been called
> > WARNING: java.lang.System::load has been called by
> > org.fusesource.jansi.internal.JansiLoader in an unnamed module
> > (file:/Users/amrk/.sdkman/candidates/maven/current/lib/jansi-2.4.1.jar)
> > WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for
> > callers in this module
> > WARNING: Restricted methods will be blocked in a future release unless
> > native access is enabled
> >
> > I also see that jansi:2.4.2 has been released (although not appearing in
> > the Changelog yet):
> >
> > org.fusesource.jansi:jansi:2.4.2   29 Apr 2025 at
> > 18:27 (NZST)
> >
> > Although looking at
> > https://github.com/fusesource/jansi/compare/jansi-2.4.1...jansi-2.4.2 it
> > doesn’t look like anything here will help with this.
> >
> > Not sure if there’s a ticket already for this (I may have raised one awhile
> > ago?) - is there any quick win/fix to hide/remove those warnings we could
> > get in a 3.9.10 release?
> >
> > Mark
> >
> > --
> > "Great artists are extremely selfish and arrogant things" — Steven Wilson,
> > Porcupine Tree
> >
> >
> > On 28 Apr 2025 at 11:58:34 PM, Tamás Cservenák 
> > wrote:
> >
> > > Howdy,
> > >
> > > quickly scanned some recent MNG JIRAs, and I think these would be good
> > > candidates as well:
> > >
> > > - https://issues.apache.org/jira/browse/MNG-8685 (limited mode, maybe
> > > only GHA along the lines of original PR?)
> > > - https://issues.apache.org/jira/browse/MNG-8663 (ASM update, it might
> > > happen already in 3.9.x) - but along with the sisu and guice switch to
> > > asm-less (non shaded) versions
> > > - https://issues.apache.org/jira/browse/MNG-8623 -- this is more
> > > "infra", make ITs use Mimir for caching just like master
> > > - https://issues.apache.org/jira/browse/MNG-8638 -- not backporting,
> > > but warning only? Also, IMO warning ONLY if values left uninterpolated
> > >
> > > will report with more
> > >
> > > On Fri, Apr 25, 2025 at 10:56 AM Tamás Cservenák 
> > > wrote:
> > >
> > >
> > > Hej,
> > >
> > >
> > > Will take a peek and I think there is more to (both resolver and mvn3) it
> > > next week
> > >
> > >
> > > T
> > >
> > >
> > > On Thu, Apr 24, 2025, 23:31 Slawomir Jaranowski 
> > > wrote:
> > >
> > > >
> > >
> > > > Hi,
> > >
> > > >
> > >
> > > > I would like to release Maven 3.9.10
> > >
> > > >
> > >
> > > > We have planned issues:
> > >
> > > >
> > >
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.10
> > >
> > > >
> > >
> > > > I also would like to release resolver 1.9.23
> > >
> > > > with issues:
> > >
> > > >
> > >
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.23
> > >
> > > >
> > >
> > > > I will work on it, I hope the release can be done in the next two -
> > > three weeks.
> > >
> > > > Any help as usual is appreciated.
> > >
> > > >
> > >
> > > >
> > >
> > > > --
> > >
> > > > Sławomir Jaranowski
> > >
> > > >
> > >
> > > > -
> > >
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > >
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >

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

Re: [HEADS UP] Maven 3.9.10 release

[Jeremy Landis]

For grins, I updated guava to latest in 3.9.9 distribution.   That issue went 
away then guice popped up.  Guice can be updated to 6.0.0.  However, that won't 
solve its warning and 7.0.0 is not usable with Maven 3.9.9 since its jakarta 
only. So not sure if that one is fixed at jakarta or not but considering both 
namespaces are needed even in maven 4, maven is likely stuck at 6.

Jansi 2.4.2 patch didn't solve its issue at all.

I think to get those two addressed, it needs fixed at the source repos and 
unlikely to find its way to maven 3.9.10.  But if those could get fixed, maybe 
maven 3.10.0 could show up later...

Sent from my Verizon, Samsung Galaxy smartphone
Get Outlook for Android

From: Gary Gregory 
Sent: Thursday, May 1, 2025 12:41:18 AM
To: Maven Developers List 
Subject: Re: [HEADS UP] Maven 3.9.10 release

Could MAVEN_ARGS or MAVEN_OPTS be used for this?

Gary

On Thu, May 1, 2025 at 12:22 AM Guillaume Nodet  wrote:
>
> The only way is to add the --enable-native-access=ALL-UNNAMED option in the
> shell scripts afaik.  We've already added it in master.
> Note that this option is not available in older JDK which are still
> supported by Maven 3.9.
>
> 
> Guillaume Nodet
>
>
>
> Le jeu. 1 mai 2025 à 05:19, Mark Derricutt  a écrit :
>
> > Tamás, Guillaume -
> >
> > I note when running 3.9.9 under Java 24, I see:
> >
> > WARNING: A restricted method in java.lang.System has been called
> > WARNING: java.lang.System::load has been called by
> > org.fusesource.jansi.internal.JansiLoader in an unnamed module
> > (file:/Users/amrk/.sdkman/candidates/maven/current/lib/jansi-2.4.1.jar)
> > WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for
> > callers in this module
> > WARNING: Restricted methods will be blocked in a future release unless
> > native access is enabled
> >
> > I also see that jansi:2.4.2 has been released (although not appearing in
> > the Changelog yet):
> >
> > org.fusesource.jansi:jansi:2.4.2   29 Apr 2025 at
> > 18:27 (NZST)
> >
> > Although looking at
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ffusesource%2Fjansi%2Fcompare%2Fjansi-2.4.1...jansi-2.4.2&data=05%7C02%7C%7C0dab12f1b10b463b1c3a08dd886a8725%7C84df9e7fe9f640afb435%7C1%7C0%7C638816713310011561%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=od5osSHgttX3swbTOh5L%2FIgacDmPsqgHXhHz7ztjCgw%3D&reserved=0
> >  it
> > doesn’t look like anything here will help with this.
> >
> > Not sure if there’s a ticket already for this (I may have raised one awhile
> > ago?) - is there any quick win/fix to hide/remove those warnings we could
> > get in a 3.9.10 release?
> >
> > Mark
> >
> > --
> > "Great artists are extremely selfish and arrogant things" — Steven Wilson,
> > Porcupine Tree
> >
> >
> > On 28 Apr 2025 at 11:58:34 PM, Tamás Cservenák 
> > wrote:
> >
> > > Howdy,
> > >
> > > quickly scanned some recent MNG JIRAs, and I think these would be good
> > > candidates as well:
> > >
> > > - 
> > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FMNG-8685&data=05%7C02%7C%7C0dab12f1b10b463b1c3a08dd886a8725%7C84df9e7fe9f640afb435%7C1%7C0%7C638816713310127577%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=TDo6PTSLdRWARTdIsP1NayxmtLUxDAx5K6d1IZzH2l4%3D&reserved=0
> > >  (limited mode, maybe
> > > only GHA along the lines of original PR?)
> > > - 
> > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FMNG-8663&data=05%7C02%7C%7C0dab12f1b10b463b1c3a08dd886a8725%7C84df9e7fe9f640afb435%7C1%7C0%7C638816713310143819%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=XRx17Y95kAkfN95f44%2B6CTYzMSEEEAwob4tpR%2BwFe88%3D&reserved=0
> > >  (ASM update, it might
> > > happen already in 3.9.x) - but along with the sisu and guice switch to
> > > asm-less (non shaded) versions
> > > - 
> > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FMNG-8623&data=05%7C02%7C%7C0dab12f1b10b463b1c3a08dd886a8725%7C84df9e7fe9f640afb435%7C1%7C0%7C638816713310158990%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=TqUa6g1KtOSjBGMBKbi78OmKCiNDbboxlVWMUGWj0kc%3D&reserved=0
> > >  -- this is more
> > > "infra", make ITs use Mimir for caching just like master
> > > -

Re: [HEADS UP] Maven 3.9.10 release

[Guillaume Nodet]

The user can configure MAVEN_OPTS yes.  Or .mvn/jvm.config.

The real problem is that adding the option will fail if running on an older
JDK which did not have that option.
What we have in master is a snippet that detects if we're running on JDK
17.  In the case of master, it's used to make sure Maven is running on JDK
>= 17.  But we could use the same mechanism in Maven 3.9 to add the needed
option if the current JDK is >= 17:

https://github.com/apache/maven/blob/master/apache-maven/src/assembly/maven/bin/mvn#L110-L115

Le jeu. 1 mai 2025 à 06:41, Gary Gregory  a écrit :

> Could MAVEN_ARGS or MAVEN_OPTS be used for this?
>
> Gary
>
> On Thu, May 1, 2025 at 12:22 AM Guillaume Nodet  wrote:
> >
> > The only way is to add the --enable-native-access=ALL-UNNAMED option in
> the
> > shell scripts afaik.  We've already added it in master.
> > Note that this option is not available in older JDK which are still
> > supported by Maven 3.9.
> >
> > 
> > Guillaume Nodet
> >
> >
> >
> > Le jeu. 1 mai 2025 à 05:19, Mark Derricutt  a écrit :
> >
> > > Tamás, Guillaume -
> > >
> > > I note when running 3.9.9 under Java 24, I see:
> > >
> > > WARNING: A restricted method in java.lang.System has been called
> > > WARNING: java.lang.System::load has been called by
> > > org.fusesource.jansi.internal.JansiLoader in an unnamed module
> > > (file:/Users/amrk/.sdkman/candidates/maven/current/lib/jansi-2.4.1.jar)
> > > WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for
> > > callers in this module
> > > WARNING: Restricted methods will be blocked in a future release unless
> > > native access is enabled
> > >
> > > I also see that jansi:2.4.2 has been released (although not appearing
> in
> > > the Changelog yet):
> > >
> > > org.fusesource.jansi:jansi:2.4.2   29 Apr 2025
> at
> > > 18:27 (NZST)
> > >
> > > Although looking at
> > > https://github.com/fusesource/jansi/compare/jansi-2.4.1...jansi-2.4.2
> it
> > > doesn’t look like anything here will help with this.
> > >
> > > Not sure if there’s a ticket already for this (I may have raised one
> awhile
> > > ago?) - is there any quick win/fix to hide/remove those warnings we
> could
> > > get in a 3.9.10 release?
> > >
> > > Mark
> > >
> > > --
> > > "Great artists are extremely selfish and arrogant things" — Steven
> Wilson,
> > > Porcupine Tree
> > >
> > >
> > > On 28 Apr 2025 at 11:58:34 PM, Tamás Cservenák 
> > > wrote:
> > >
> > > > Howdy,
> > > >
> > > > quickly scanned some recent MNG JIRAs, and I think these would be
> good
> > > > candidates as well:
> > > >
> > > > - https://issues.apache.org/jira/browse/MNG-8685 (limited mode,
> maybe
> > > > only GHA along the lines of original PR?)
> > > > - https://issues.apache.org/jira/browse/MNG-8663 (ASM update, it
> might
> > > > happen already in 3.9.x) - but along with the sisu and guice switch
> to
> > > > asm-less (non shaded) versions
> > > > - https://issues.apache.org/jira/browse/MNG-8623 -- this is more
> > > > "infra", make ITs use Mimir for caching just like master
> > > > - https://issues.apache.org/jira/browse/MNG-8638 -- not backporting,
> > > > but warning only? Also, IMO warning ONLY if values left
> uninterpolated
> > > >
> > > > will report with more
> > > >
> > > > On Fri, Apr 25, 2025 at 10:56 AM Tamás Cservenák <
> ta...@cservenak.net>
> > > > wrote:
> > > >
> > > >
> > > > Hej,
> > > >
> > > >
> > > > Will take a peek and I think there is more to (both resolver and
> mvn3) it
> > > > next week
> > > >
> > > >
> > > > T
> > > >
> > > >
> > > > On Thu, Apr 24, 2025, 23:31 Slawomir Jaranowski <
> s.jaranow...@gmail.com>
> > > > wrote:
> > > >
> > > > >
> > > >
> > > > > Hi,
> > > >
> > > > >
> > > >
> > > > > I would like to release Maven 3.9.10
> > > >
> > > > >
> > > >
> > > > > We have planned issues:
> > > >
> > > > >
> > > >
> > >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.10
> > > >
> > > > >
> > > >
> > > > > I also would like to release resolver 1.9.23
> > > >
> > > > > with issues:
> > > >
> > > > >
> > > >
> > >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.23
> > > >
> > > > >
> > > >
> > > > > I will work on it, I hope the release can be done in the next two -
> > > > three weeks.
> > > >
> > > > > Any help as usual is appreciated.
> > > >
> > > > >
> > > >
> > > > >
> > > >
> > > > > --
> > > >
> > > > > Sławomir Jaranowski
> > > >
> > > > >
> > > >
> > > > >
> -
> > > >
> > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > >
> > > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > >
> > > > >
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> 

Re: [HEADS UP] Maven 3.9.10 release

[Michael Bien]

On 5/1/25 06:21, Guillaume Nodet wrote:
> The only way is to add the --enable-native-access=ALL-UNNAMED option in the
> shell scripts afaik.  We've already added it in master.
> Note that this option is not available in older JDK which are still
> supported by Maven 3.9.

-XX:+IgnoreUnrecognizedVMOptions should allow setting that flag on older JDKs 
without a launch failure.

its not great since this will obfuscate typos etc but sometimes useful in 
situations like this,

best regards,

michael


>
> 
> Guillaume Nodet
>
>
>
> Le jeu. 1 mai 2025 à 05:19, Mark Derricutt  a écrit :
>
>> Tamás, Guillaume -
>>
>> I note when running 3.9.9 under Java 24, I see:
>>
>> WARNING: A restricted method in java.lang.System has been called
>> WARNING: java.lang.System::load has been called by
>> org.fusesource.jansi.internal.JansiLoader in an unnamed module
>> (file:/Users/amrk/.sdkman/candidates/maven/current/lib/jansi-2.4.1.jar)
>> WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for
>> callers in this module
>> WARNING: Restricted methods will be blocked in a future release unless
>> native access is enabled
>>
>> I also see that jansi:2.4.2 has been released (although not appearing in
>> the Changelog yet):
>>
>> org.fusesource.jansi:jansi:2.4.2   29 Apr 2025 at
>> 18:27 (NZST)
>>
>> Although looking at
>> https://github.com/fusesource/jansi/compare/jansi-2.4.1...jansi-2.4.2 it
>> doesn’t look like anything here will help with this.
>>
>> Not sure if there’s a ticket already for this (I may have raised one awhile
>> ago?) - is there any quick win/fix to hide/remove those warnings we could
>> get in a 3.9.10 release?
>>
>> Mark
>>
>> --
>> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
>> Porcupine Tree
>>
>>
>> On 28 Apr 2025 at 11:58:34 PM, Tamás Cservenák 
>> wrote:
>>
>>> Howdy,
>>>
>>> quickly scanned some recent MNG JIRAs, and I think these would be good
>>> candidates as well:
>>>
>>> - https://issues.apache.org/jira/browse/MNG-8685 (limited mode, maybe
>>> only GHA along the lines of original PR?)
>>> - https://issues.apache.org/jira/browse/MNG-8663 (ASM update, it might
>>> happen already in 3.9.x) - but along with the sisu and guice switch to
>>> asm-less (non shaded) versions
>>> - https://issues.apache.org/jira/browse/MNG-8623 -- this is more
>>> "infra", make ITs use Mimir for caching just like master
>>> - https://issues.apache.org/jira/browse/MNG-8638 -- not backporting,
>>> but warning only? Also, IMO warning ONLY if values left uninterpolated
>>>
>>> will report with more
>>>
>>> On Fri, Apr 25, 2025 at 10:56 AM Tamás Cservenák 
>>> wrote:
>>>
>>>
>>> Hej,
>>>
>>>
>>> Will take a peek and I think there is more to (both resolver and mvn3) it
>>> next week
>>>
>>>
>>> T
>>>
>>>
>>> On Thu, Apr 24, 2025, 23:31 Slawomir Jaranowski 
>>> wrote:
>>>
 Hi,
 I would like to release Maven 3.9.10
 We have planned issues:
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.10
 I also would like to release resolver 1.9.23
 with issues:
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.23
 I will work on it, I hope the release can be done in the next two -
>>> three weeks.
>>>
 Any help as usual is appreciated.
 --
 Sławomir Jaranowski
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>>


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

Re: [VOTE] Require Java 21 for Maven 4 (Rephrased Vote)

[Grzegorz Grzybek]

+1 (non-binding)

 - JEP 400: UTF-8 by Default (JDK18)
 - JEP 418: Internet-Address Resolution SPI (JDK18)
 - JEP 444: Virtual Threads (JDK21)

regards
Grzegorz Grzybek

śr., 30 kwi 2025 o 21:50 Elliotte Rusty Harold 
napisał(a):

> -1
>
> On Wed, Apr 30, 2025 at 1:12 PM Matthias Bünger 
> wrote:
> >
> > Hi everyone,
> > over the last years we had several discussions about lifting the
> > required Java version to run Maven from 8 to something higher. You can
> > find them in the mail archive.
> > In February 2024 we decided to lift it to 17 (see result: [1*]).
> >
> > An argument to pick 17 instead of 21 was to take the (at the point of
> > voting) second last JDK for which vendors offer LTS (Note: LTS is
> > important for companies).
> > With Java 25 (next with LTS) coming in September and a final Maven 4.0.0
> > on the horizon (no date yet), I think we should raise the minimum
> > version once more and use Java 21, which will be the second last
> > "LTS-JDK" in September. Doing this brings the benefit of avoid locking
> > into an "already considered old" version (and of course the improvements
> > of Java 18-21).
> >
> > In a chat with several PMC, committers and contributors nobody saw
> > strong disadvantages on this. Therefore, I want to start the official
> > vote to set the minimal Java bytecode target of Maven-Core 4 to 21,
> > meaning Java 21 is required for Maven 4.
> >
> > This is a procedural majority vote [2*]. You can also vote with
> > fractions and negative votes are not vetoes.
> > Please refrain from starting discussions in this thread, but do include
> > a reasoning on downvotes and feel free to start a new discussion on the
> > mailing list.
> >
> > The vote is open for at least 72 hours.
> >
> > Please also notice:
> > * Maven 3 will stay at Java 8.
> > * It's about the minimum Java version to run Maven 4, not to compile
> > applications against. With Java 21 you can compile down to Java 8. For
> > special JDK needs, also toolchain tools can be used.
> >
> >
> > Have a sunny day everyone
> >
> > Matthias
> >
> > [1*]: https://lists.apache.org/thread/bfkvvjftrxypp06yj8zj919fcz0dt2zt
> > [2*]: https://www.apache.org/foundation/voting.html
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [HEADS UP] Maven 3.9.10 release

[Mark Derricutt]

Tamás, Guillaume -

I note when running 3.9.9 under Java 24, I see:

WARNING: A restricted method in java.lang.System has been called
WARNING: java.lang.System::load has been called by
org.fusesource.jansi.internal.JansiLoader in an unnamed module
(file:/Users/amrk/.sdkman/candidates/maven/current/lib/jansi-2.4.1.jar)
WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for
callers in this module
WARNING: Restricted methods will be blocked in a future release unless
native access is enabled

I also see that jansi:2.4.2 has been released (although not appearing in
the Changelog yet):

org.fusesource.jansi:jansi:2.4.2   29 Apr 2025 at
18:27 (NZST)

Although looking at
https://github.com/fusesource/jansi/compare/jansi-2.4.1...jansi-2.4.2 it
doesn’t look like anything here will help with this.

Not sure if there’s a ticket already for this (I may have raised one awhile
ago?) - is there any quick win/fix to hide/remove those warnings we could
get in a 3.9.10 release?

Mark

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


On 28 Apr 2025 at 11:58:34 PM, Tamás Cservenák  wrote:

> Howdy,
>
> quickly scanned some recent MNG JIRAs, and I think these would be good
> candidates as well:
>
> - https://issues.apache.org/jira/browse/MNG-8685 (limited mode, maybe
> only GHA along the lines of original PR?)
> - https://issues.apache.org/jira/browse/MNG-8663 (ASM update, it might
> happen already in 3.9.x) - but along with the sisu and guice switch to
> asm-less (non shaded) versions
> - https://issues.apache.org/jira/browse/MNG-8623 -- this is more
> "infra", make ITs use Mimir for caching just like master
> - https://issues.apache.org/jira/browse/MNG-8638 -- not backporting,
> but warning only? Also, IMO warning ONLY if values left uninterpolated
>
> will report with more
>
> On Fri, Apr 25, 2025 at 10:56 AM Tamás Cservenák 
> wrote:
>
>
> Hej,
>
>
> Will take a peek and I think there is more to (both resolver and mvn3) it
> next week
>
>
> T
>
>
> On Thu, Apr 24, 2025, 23:31 Slawomir Jaranowski 
> wrote:
>
> >
>
> > Hi,
>
> >
>
> > I would like to release Maven 3.9.10
>
> >
>
> > We have planned issues:
>
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.9.10
>
> >
>
> > I also would like to release resolver 1.9.23
>
> > with issues:
>
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.23
>
> >
>
> > I will work on it, I hope the release can be done in the next two -
> three weeks.
>
> > Any help as usual is appreciated.
>
> >
>
> >
>
> > --
>
> > Sławomir Jaranowski
>
> >
>
> > -
>
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>