Re: [VOTE] Require Java 21 for Maven 4 (Rephrased Vote)
-1 Not sure what is the real missing mandatory feature for Maven 4.0.x we do not have with 17. I can only see this could prevent a lot of users from migrating to 4.0.x (something we probably do not want) I would say maybe for 4.1.x but again what is the real missing JDK 21 feature we really need for Maven 4.0.x On Wed, 30 Apr 2025 at 23: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)
-1 I such I don't see a benefit for code, and it is RC stage, we should not introduce such big changes On Wed, 30 Apr 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 > -- Sławomir Jaranowski - 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)
I'm not sure how you can consider this a procedural change. What sort of procedure do we change here? I feel it is more like a code change, as it definitely touches code. On Wed, 30 Apr 2025 at 23: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)
As much as I would like to use a modern version of Java, I also agree with Michael on this. It's simply too late for Maven 4. -1 Maarten On 02/05/2025 10:02, Michael Osipov wrote: -1 Changing such an important requirement in the RC phase isn't professional. On 2025/04/30 13:12:43 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 - 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)
-1 I saw no benefit cited to going to 21, only implicit new constraints to users I just saw the logic we used to skip 11 and go to 17 reused because we did not ship 4.0 yet I prefer shipping 4.0 with constraints people expected for 4.0 during the release candidates: we'll see on next releases Regards, Hervé - Mail original - De: "Matthias Bünger" À: "Maven Developers List" Cc: "Maven Users List" Envoyé: Mercredi 30 Avril 2025 15:12:43 Objet: [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: [DISCUSS] Publishing to Central + Maveniverse Njord
Hi all, thank you for your long mail and the good abstraction of the problem including the difference of deploying and publishing. As I have little to no experience in publishing and releasing to central, I can't say much to the technical part, but only write something from a users perspective as I / my team use the maven-deploy-plugin to deploy our artifact to the company Nexus. I agree that Maven can't and therefore should not try to define a publishing process - it's something "management" defines, but not a tool. However, Maven should ship a tool/plugin to do the technical deployment to a repository manager and not stop shortly before it, leaving the user in / introducing a "well you now have to leave maven universe - come back when you have deployed your artifact and want to use it" hole. For me personal it's totally fine to do exploration in Njord and then integrate its mechanism to Maven. It's natural to software core projects and libraries to move/integrate ideas. Have a nice evening Matthias Am 30.04.2025 um 17:16 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
[RESULT][VOTE] Require Java 21 for Maven 4 (Rephrased Vote)
Morning everyone, first I would like to thank everybody who participated in the vote [*1] about lifting the required Java version to 21 for Maven 4.0.0. The vote has ended with the following votes: -- Binding votes: +1: Sylwester Lachiewicz, Karl Heinz Marbaise, Tamás Cservenák, Benjamin Marwell, Arnaud Héritier, Tibor Digaňa -1: Michael Osipov, Maarten Mulders, Olivier Lamy, Slawomir Jaranowski, Hervé Boutemy Non-binding votes: +1: Gary Gregory, Mateusz Gajewski, Mantas Gridinas, Rodrigo Bourbon, Willker Gomes, Hans Aikema, Martin Desruisseaux, Torsten Heit, Sandra Parsick, Dawid Law, Philipp Picej, John Neffenger, Jeremy Landis, Daniel B. Widdis, Michael Bien, Gregorz Grzybek, Kévin Buntrock, Jorge Solorzano, Mark Derricutt, Matthias Bünger, Basil Crow, Romain Manni-Bucau, Thomas Sundberg, Anders Hammar, Piotr P. Karwasz, Niels Basjes, Enrico Olivelli -1: Elliotte Rusty Harold -- 5 out of 11 binding votes are -1 with valid arguments, including that there is no actual need to upgrade, that (it's too late, as ) we are already in RC phase, and that it might put on new constraints to users. The vote was (in line to the vote about lifting Maven 4 to Java 17) a "procedural majority vote", meaing a simple majority of binding votes would be enough to considered it to be passed. But due the high number of negative votes and brought up arguments, I don't think we should ignore them but take them into consideration for the benefit of the Maven community. Therefore I call the vote to be non successful. We can reevaluate in the future, including having a closer look at / discussion about the benefits and constraints of raising the Java version. Wish you a happy sunday! Matthias [*1]: https://lists.apache.org/thread/mjbx64vlbd346ov3l4wj6fy9vh8608vr - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
