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

[Matthias Bünger]

+1 (non binding)

Am 30.04.2025 um 15:12 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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-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)

[Basil Crow]

+1 (non binding)

-
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)

[Kévin Buntrock]

+1 here. And wishing a great day to everyone.

Le jeu. 1 mai 2025, 08:24, Grzegorz Grzybek  a écrit :

> +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

[Elliotte Rusty Harold]

JAnsi seems like a frequent source of issues like this. Ideally I'd
like to get rid of it, but I'm  not sure how much effort that would
be.

On Thu, May 1, 2025 at 3:19 AM Mark Derricutt  wrote:
>
> 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
> >
> >



-- 
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

Permission to merge?

[Martin Desruisseaux]

Hello

There is two branches that we could merge, but I would like to 
double-check on this list before to move ahead.


The first pull request (PR) is replacing Plexus dependency by java.nio 
in the maven-clean-plugin. This PR got two reviewers approval, so in my 
understanding I could merge, but I would like to verify if this is a 
correct understanding:


   https://github.com/apache/maven-clean-plugin/pull/243

The second pull request is a refactoring of the maven-compiler-plugin 
(NOT including the module-info-patch proposed in a previous thread - 
that one is kept in a separated branch). While that PR got only one 
approval, I suspect it may be difficult to get more because of the size 
of the changes. The problem is that new developments are added on top of 
this PR instead of on master, for avoiding future merge conflicts. 
Therefore, this PR is slowly growing with new fixes are that not 
directly the initial PR scope.


   https://github.com/apache/maven-compiler-plugin/pull/320

That pull request fixes the following issues as side-effect of the 
refactoring, or with bug fixes added after the initial PR:


 * #308 Bump mavenVersion from 4.0.0-rc-2 to 4.0.0-rc-3
 * #319 Bump
   org.apache.maven.plugin-testing:maven-plugin-testing-harness from
   4.0.0-beta-3 to 4.0.0-beta-4
 * #326 API incompatibility when using Maven 4.0.0-RC3
 * #327 master does not build on windows with Maven 4.0.0-rc-3
 * #193 Use relative paths in jpms.args to make the builds reproducible
 * #160 This plugin is not "incremental"
 * #27 (under some conditions) fix test compile issue: added dependency
   test path for modules
 * Wrong encoding when reading the output of forked JVM on Windows

Martin

Re: [HEADS UP] Maven 3.9.10 release

[Slawomir Jaranowski]

On Thu, 1 May 2025 at 06:22, 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.

It was done in https://github.com/apache/maven/pull/2171

>
> 
> 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
> > >
> > >
> >



-- 
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)

[Romain Manni-Bucau]

+1, libraries will enforce it at some point to be properly functional so
better to not start late with first 4.0.0

Romain Manni-Bucau
@rmannibucau  | .NET Blog
 | Blog  | Old
Blog  | Github
 | LinkedIn
 | Book



Le jeu. 1 mai 2025 à 18:27, Basil Crow  a écrit :

> +1 (non binding)
>
> -
> 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)

[Jorge Solorzano]

+1 (non-binding)

-
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

[Slawomir Jaranowski]

On Mon, 28 Apr 2025 at 13:59, 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?)

There is no support for CI system in 3.9.x - we can copy try to copy
classes from package - org.apache.maven.cling.invoker.cisupport
and simpy use it to set batch and verbose mode ... but probably we
also need an option `force-interactive` ...

Look like new feature for 3.10.x ...

> - 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

We can try it ...


> - https://issues.apache.org/jira/browse/MNG-8623 -- this is more
> "infra", make ITs use Mimir for caching just like master

It can be done in any time,  no release depends


> - 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
>


-- 
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)

[Tibor Digana]

+1
Tibor Digana

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: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Release tag format for Maven projects

[Tamás Cservenák]

Howdy,

I don't see why we want to change tag format (!) on existing,
especially long time existing and running projects.
What gain does it give ASIDE for some tooling nicer output, that we
never used before (that generates something out of it)?
How to sort history after? How to process tags for some automation
when it changes in the middle?

I am really against doing this "right in the middle".

Changing tag format on brand new projects makes sense to me (before
the first tag is done),
but doing it "as we go"?

As for GH release notes I always _remove_ the prefix (ie. tag is
foo-3.4.1 then release title is 3.4.1, same as project.version).
Having this "v${project.version}" ONLY to spare for this string op is
-1 for me, plus it most probably breaks git automatic processing as
well, no?




On Thu, May 1, 2025 at 10:30 PM Slawomir Jaranowski
 wrote:
>
> Hi,
>
> We introduce a short and the same template release tag name for Maven
> projects as:
>
> v@{project.version}
>
> in parent 44: https://github.com/apache/maven-parent/pull/455
>
> It will change a tag name on history ... but for me is more modern and
> simplified other configurations like for release-drafter
>
> It is also used in GitHub to point release notes, eg
>
> old tga format
> https://github.com/apache/maven-clean-plugin/releases/tag/maven-clean-plugin-3.4.1
>
> new tag format:
> https://github.com/apache/maven-parent/releases/tag/v44
>
> so we don't have a duplicate component name in the path.
>
>
> Any objections for the new tag format ...?
>
> --
> 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: Release tag format for Maven projects

[Tamás Cservenák]

Explanation: I am talking about some automation that for example uses
JGit to get version information and so on... so "sorting on GH UI" is
one thing, but automatic processing of tags by various means is
completely different.

T

On Thu, May 1, 2025 at 10:37 PM Tamás Cservenák  wrote:
>
> Howdy,
>
> I don't see why we want to change tag format (!) on existing,
> especially long time existing and running projects.
> What gain does it give ASIDE for some tooling nicer output, that we
> never used before (that generates something out of it)?
> How to sort history after? How to process tags for some automation
> when it changes in the middle?
>
> I am really against doing this "right in the middle".
>
> Changing tag format on brand new projects makes sense to me (before
> the first tag is done),
> but doing it "as we go"?
>
> As for GH release notes I always _remove_ the prefix (ie. tag is
> foo-3.4.1 then release title is 3.4.1, same as project.version).
> Having this "v${project.version}" ONLY to spare for this string op is
> -1 for me, plus it most probably breaks git automatic processing as
> well, no?
>
>
>
>
> On Thu, May 1, 2025 at 10:30 PM Slawomir Jaranowski
>  wrote:
> >
> > Hi,
> >
> > We introduce a short and the same template release tag name for Maven
> > projects as:
> >
> > v@{project.version}
> >
> > in parent 44: https://github.com/apache/maven-parent/pull/455
> >
> > It will change a tag name on history ... but for me is more modern and
> > simplified other configurations like for release-drafter
> >
> > It is also used in GitHub to point release notes, eg
> >
> > old tga format
> > https://github.com/apache/maven-clean-plugin/releases/tag/maven-clean-plugin-3.4.1
> >
> > new tag format:
> > https://github.com/apache/maven-parent/releases/tag/v44
> >
> > so we don't have a duplicate component name in the path.
> >
> >
> > Any objections for the new tag format ...?
> >
> > --
> > 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

Release tag format for Maven projects

[Slawomir Jaranowski]

Hi,

We introduce a short and the same template release tag name for Maven
projects as:

v@{project.version}

in parent 44: https://github.com/apache/maven-parent/pull/455

It will change a tag name on history ... but for me is more modern and
simplified other configurations like for release-drafter

It is also used in GitHub to point release notes, eg

old tga format
https://github.com/apache/maven-clean-plugin/releases/tag/maven-clean-plugin-3.4.1

new tag format:
https://github.com/apache/maven-parent/releases/tag/v44

so we don't have a duplicate component name in the path.


Any objections for the new tag format ...?

-- 
Sławomir Jaranowski

-
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

[Piotr P. Karwasz]

Hi Jeremy,

On 30.04.2025 18:26, Jeremy Landis wrote:

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.


The CycloneDX Maven Plugin is not the only one that will incorrectly 
detect, which artifacts are deployed. I copied the deployment detection 
code from Maven Artifact Plugin:


https://github.com/apache/maven-artifact-plugin/blob/master/src/main/java/org/apache/maven/plugins/artifact/buildinfo/PluginUtil.java

That code is clearly a hack, but as far as I know, there is no better 
alternative right now. Maybe something could be introduced in the Maven 
4 model.


Piotr


-
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)

[Piotr P. Karwasz]

Hi,

On 30.04.2025 15:12, Matthias Bünger wrote:
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.



+1 (non-binding)

The key "feature" that JDK 21 has is that `--release 8` is still 
supported, although a warning started to appear.


Piotr


-
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)

[Mark Derricutt]

 +1 non binding.

Bring on the new world!

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

On 1 May 2025 at 6:23:47 PM, Grzegorz Grzybek  wrote:

> +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: [VOTE] Require Java 21 for Maven 4 (Rephrased Vote)

[Anders Hammar]

+1

/Anders (mobile)

Den ons 30 apr. 2025 15:12Matthias Bünger  skrev:

> 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
>
>