You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Guillaume Nodet <gn...@apache.org> on 2025/05/21 06:11:42 UTC
Maven 4.0.0 Release - Thoughts?
Hey Maven Devs,
We're gearing up to release a new version from the master branch. I'm
thinking we should go for 4.0.0 instead of rc-4. What do you all think? Any
feedback or ideas on the versioning or release plan? Let’s hear it!
Cheers,
Guillaume
Re: Maven 4.0.0 Release - Thoughts?
Posted by Mateusz Gajewski <ma...@starburstdata.com>.
+1 (nb) Greatest release of them all!
On Wed, May 21, 2025 at 08:21 Romain Manni-Bucau <rm...@gmail.com>
wrote:
> +1
>
> Romain Manni-Bucau
> @rmannibucau <https://x.com/rmannibucau> | .NET Blog
> <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/>
> | Old
> Blog <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064
> >
>
>
> Le mer. 21 mai 2025 à 08:11, Guillaume Nodet <gn...@apache.org> a écrit :
>
> > Hey Maven Devs,
> >
> > We're gearing up to release a new version from the master branch. I'm
> > thinking we should go for 4.0.0 instead of rc-4. What do you all think?
> Any
> > feedback or ideas on the versioning or release plan? Let’s hear it!
> >
> > Cheers,
> >
> > Guillaume
> >
>
Re: Maven 4.0.0 Release - Thoughts?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+1
Romain Manni-Bucau
@rmannibucau <https://x.com/rmannibucau> | .NET Blog
<https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old
Blog <http://rmannibucau.wordpress.com> | Github
<https://github.com/rmannibucau> | LinkedIn
<https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064>
Le mer. 21 mai 2025 à 08:11, Guillaume Nodet <gn...@apache.org> a écrit :
> Hey Maven Devs,
>
> We're gearing up to release a new version from the master branch. I'm
> thinking we should go for 4.0.0 instead of rc-4. What do you all think? Any
> feedback or ideas on the versioning or release plan? Let’s hear it!
>
> Cheers,
>
> Guillaume
>
Re: Maven 4.0.0 Release - Thoughts?
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
-1.
I'm fine with feature freeze, but the codebase and API have not
reached a stable and reliable state that I'm comfortable committing
to. In particular, there is a lot of API still marked experimental,
and I think we need to make decisions on all of that before pushing a
release version out the door.
I'd also like to see better documentation of the system design and
API, as well as a full review of the design from a high level to see
if it all makes sense. I don't want to ship it now only to notice in
six months that something is seriously wonky.
On Wed, May 21, 2025 at 6:12 AM Guillaume Nodet <gn...@apache.org> wrote:
>
> Hey Maven Devs,
>
> We're gearing up to release a new version from the master branch. I'm
> thinking we should go for 4.0.0 instead of rc-4. What do you all think? Any
> feedback or ideas on the versioning or release plan? Let’s hear it!
>
> Cheers,
>
> Guillaume
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0 Release - Thoughts?
Posted by Hervé Boutemy <hb...@apache.org>.
I think we need to clarify that
1. Maven 3 plugins should work with Maven 4 (eventually require a recent
update that fixes small compatibility issues),
2. and this is still the main expected way to use plugins with Maven 4
Maven 4 - specific plugins, using the still experimental Maven 4 API, is still
a future thing in preparation in Maven 4.0.0
I suppose we can expect that Maven 4 API will further stabilize with Maven 4.1
And also clarify which Maven 3 plugins are definitively not compatible with
Maven 4 and will absolutely require a Maven 4 specific one = know the exception
to the norm
I think that what I'm writing here is not wrong = why shipping as-is is
adapted
if there is stronger expectation on Maven 4 (plugin) API stability, good luck
with the chicken and egg question given the wide ecosystem of plugins
Regards,
Hervé
Le dimanche 25 mai 2025, 12:26:11 CEST Elliotte Rusty Harold a écrit :
> On Sat, May 24, 2025 at 1:23 PM Guillaume Nodet <gn...@apache.org> wrote:
> > I don't think they're talking about the Maven 4 API when they expect
> > API stability.
> > They rather refer to user-facing API such as schema changes, etc...,
> > rather than dev-facing API.
>
> Plugin developers need API stability though.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0 Release - Thoughts?
Posted by Guillaume Nodet <gn...@apache.org>.
Plugin developers aren’t forced to migrate. I’m using Maven 4 daily and I
don’t use a single plugin that uses the new api.
So while I agree that stability is required, the stability is provided by
the Maven 3 api, mostly supported unchanged in Maven 4.
Le dim. 25 mai 2025 à 12:26, Elliotte Rusty Harold <el...@ibiblio.org> a
écrit :
> On Sat, May 24, 2025 at 1:23 PM Guillaume Nodet <gn...@apache.org> wrote:
> >
> > I don't think they're talking about the Maven 4 API when they expect
> > API stability.
> > They rather refer to user-facing API such as schema changes, etc...,
> > rather than dev-facing API.
>
> Plugin developers need API stability though.
>
> --
> Elliotte Rusty Harold
> elharo@ibiblio.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven 4.0.0 Release - Thoughts?
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Sat, May 24, 2025 at 1:23 PM Guillaume Nodet <gn...@apache.org> wrote:
>
> I don't think they're talking about the Maven 4 API when they expect
> API stability.
> They rather refer to user-facing API such as schema changes, etc...,
> rather than dev-facing API.
Plugin developers need API stability though.
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0 Release - Thoughts?
Posted by Guillaume Nodet <gn...@apache.org>.
I don't think they're talking about the Maven 4 API when they expect
API stability.
They rather refer to user-facing API such as schema changes, etc...,
rather than dev-facing API.
We did introduce new features in the RC, but afaik, they're not using
the maven 4 API, I could be wrong though.
Le sam. 24 mai 2025 à 11:12, Romain Manni-Bucau
<rm...@gmail.com> a écrit :
>
> Do we have the list of planned API changes?
> Most changes can likely be limited using a "request/response object"
> pattern (so we can add data without breaking instead of passing N
> parameters), new methods dont break, so ultimately we are not worse than
> 3.9.x in terms of stability if we respect that or do respect that in the
> future.
>
> My point is that we can say the exact same reasons to never release v4
> whereas it is adopted by several people since months now so we should let
> it go and handle bugs as bugs and not as RC which doesnt mean anything
> anymore IMHO.
>
> Romain Manni-Bucau
> @rmannibucau <https://x.com/rmannibucau> | .NET Blog
> <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old
> Blog <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064>
>
>
> Le ven. 23 mai 2025 à 19:32, Benjamin Marwell <bm...@apache.org> a
> écrit :
>
> > -1 for release, +1 for rc4.
> > Reason: What Sylwester said, plus Nikita from JetBrains asking nicely.
> > They (JB) would love to see API stability so they can ship an IntelliJ
> > IDEA release in time with Maven 4.
> > This of course applies to all other IDEs.
> >
> > Nikita is on #maven in slack, maybe also subscribed here? idk.
> >
> > Anyway, really strong reasons to do an RC4 first.
> > This should not be hasted.
> >
> > - Ben
> >
> > Am Fr., 23. Mai 2025 um 00:05 Uhr schrieb Sylwester Lachiewicz
> > <sl...@gmail.com>:
> > >
> > > I would go for rc4 because we still have API changes after rc3 and our
> > > plugins needs adjustments that could again require another, smaller
> > > changes.
> > > With current state of plugins 4.x they can't be used with latest (master)
> > > version so we could offer only 3.x for Maven 4.
> > > Not so big issue for many users but without semi automatic way to move
> > > plugin to new public API we are selling new "untested internally".
> > >
> > > In my opinion, if we could have releases of core plugins based on rc4 API
> > > and our CI/CD pipelines runs also under Maven 4 - it would be safer.
> > >
> > > Sylwester
> > >
> > > śr., 21 maj 2025, 08:12 użytkownik Guillaume Nodet <gn...@apache.org>
> > > napisał:
> > >
> > > > Hey Maven Devs,
> > > >
> > > > We're gearing up to release a new version from the master branch. I'm
> > > > thinking we should go for 4.0.0 instead of rc-4. What do you all
> > think? Any
> > > > feedback or ideas on the versioning or release plan? Let’s hear it!
> > > >
> > > > Cheers,
> > > >
> > > > Guillaume
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
--
------------------------
Guillaume Nodet
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0 Release - Thoughts?
Posted by Guillaume Nodet <gn...@apache.org>.
We cannot do that. We'd have to cut a new release and vote on it.
If the goal is to evaluate the release, we need to start voting a
4.0.0, open the vote, if any issue is considered blocking, cancel the
vote, fix the issue and cut another 4.0.0 release. If the issue is not
blocking, we can do a 4.0.1 a few days or weeks later.
Le lun. 26 mai 2025 à 14:14, Nikita Skvortsov
<ni...@jetbrains.com.invalid> a écrit :
>
> I believe having a "Release Candidate" is a good idea
>
> As long as it is indeed a candidate: a version that is exactly the same as
> a release, except for discovered critical issues and version numbers.
> I wonder if promoting a candidate to a GA without any code changes requires
> modification of existing community processes.
>
> ---
> Nikita Skvortsov
> Java Build Tools Team Lead
>
> JetBrains N.V. | KvK reg. nr. 56460279
> Gelrestraat 16, 1079 MZ Amsterdam, The Netherlands
> T: + 31 (0)20 205 01 18 | F: +31 (0)20 205 01 19
> E: Nikita.Skvortsov@jetbrains.com
>
>
> On Sat, 24 May 2025 at 11:12, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Do we have the list of planned API changes?
> > Most changes can likely be limited using a "request/response object"
> > pattern (so we can add data without breaking instead of passing N
> > parameters), new methods dont break, so ultimately we are not worse than
> > 3.9.x in terms of stability if we respect that or do respect that in the
> > future.
> >
> > My point is that we can say the exact same reasons to never release v4
> > whereas it is adopted by several people since months now so we should let
> > it go and handle bugs as bugs and not as RC which doesnt mean anything
> > anymore IMHO.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://x.com/rmannibucau> | .NET Blog
> > <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/>
> > | Old
> > Blog <http://rmannibucau.wordpress.com> | Github
> > <https://github.com/rmannibucau> | LinkedIn
> > <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> > https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064
> > >
> >
> >
> > Le ven. 23 mai 2025 à 19:32, Benjamin Marwell <bm...@apache.org> a
> > écrit :
> >
> > > -1 for release, +1 for rc4.
> > > Reason: What Sylwester said, plus Nikita from JetBrains asking nicely.
> > > They (JB) would love to see API stability so they can ship an IntelliJ
> > > IDEA release in time with Maven 4.
> > > This of course applies to all other IDEs.
> > >
> > > Nikita is on #maven in slack, maybe also subscribed here? idk.
> > >
> > > Anyway, really strong reasons to do an RC4 first.
> > > This should not be hasted.
> > >
> > > - Ben
> > >
> > > Am Fr., 23. Mai 2025 um 00:05 Uhr schrieb Sylwester Lachiewicz
> > > <sl...@gmail.com>:
> > > >
> > > > I would go for rc4 because we still have API changes after rc3 and our
> > > > plugins needs adjustments that could again require another, smaller
> > > > changes.
> > > > With current state of plugins 4.x they can't be used with latest
> > (master)
> > > > version so we could offer only 3.x for Maven 4.
> > > > Not so big issue for many users but without semi automatic way to move
> > > > plugin to new public API we are selling new "untested internally".
> > > >
> > > > In my opinion, if we could have releases of core plugins based on rc4
> > API
> > > > and our CI/CD pipelines runs also under Maven 4 - it would be safer.
> > > >
> > > > Sylwester
> > > >
> > > > śr., 21 maj 2025, 08:12 użytkownik Guillaume Nodet <gn...@apache.org>
> > > > napisał:
> > > >
> > > > > Hey Maven Devs,
> > > > >
> > > > > We're gearing up to release a new version from the master branch. I'm
> > > > > thinking we should go for 4.0.0 instead of rc-4. What do you all
> > > think? Any
> > > > > feedback or ideas on the versioning or release plan? Let’s hear it!
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Guillaume
> > > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
--
------------------------
Guillaume Nodet
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0 Release - Thoughts?
Posted by Guillaume Nodet <gn...@apache.org>.
Some plugins are known to cause important slow downs when executing in Maven 4.
This is the case for example of
https://github.com/tisonkun/os-detector which can be easily replaced
with https://github.com/maveniverse/nisse.
But I suppose there are other plugins that could cause the same behavior.
Le lun. 26 mai 2025 à 22:57, Sergey Chernov <se...@gmail.com> a écrit :
>
> Just tried the 4.0.0-rc-3 comparing with 3.9.9, it's 4x times slower (!) on
> a project of ~900 modules (700 of them are jar).
> Maven 3 builds it in 2m57s, while Maven 4 in 11m48s (reproducible, with all
> m2 caches). No build cache solutions enabled to compare pure build time.
> Project is nothing special, just java 17 + kotlin 2.1 compilation (no test
> execution).
> It fits into the same heap memory. The CPU cores load is about the same
> (but 4x longer).
> It seems that somewhere there is a huge overhead.
>
> Were there other performance tests at scale?
>
>
> On Mon, May 26, 2025 at 4:48 PM Maarten Mulders <mt...@apache.org>
> wrote:
>
> > Totally agree! I'm not trying to advocate "no more RC's", I'm trying to
> > advocate "last RC should be as close as possible to the final product".
> > And given what has happened between the last RC and today, I don't think
> > we can cut 4.0.0 *today*. The diff is quite large IMO.
> >
> > Thanks,
> >
> >
> > Maarten
> >
> > On May 26th, 2025 at 16:39, Elliotte Rusty Harold wrote:
> > > On Mon, May 26, 2025 at 2:25 PM Maarten Mulders <mt...@apache.org>
> > wrote:
> > >>
> > >> That definition makes a lot of sense to me. If we would adhere to it, we
> > >> should discipline ourselves after "a" next RC and *not* accept any code
> > >> changes *except* for fixing critical uses.
> > >
> > > Be careful not to let the tail wag the dog. if changes are needed,
> > > they're needed. You just need another RC. I would actually prefer that
> > > RCs be identical to the release aside from version number, or even
> > > better that the release candidate binary could simply become the
> > > release, but that's not really how the Maven release process works.
> > > However, critical bug fixes should generate a new RC. Overall I would
> > > prefer much more rigorous versioning. Right now we're pushing RCs with
> > > known unstable APIs, which I would normally consider appropriate for
> > > pre-alpha builds.
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
--
------------------------
Guillaume Nodet
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0 Release - Thoughts?
Posted by Xeno Amess <xe...@gmail.com>.
yep, you can try with jprofiler/jetbrains-profiler/something else and see
what be the bottleneck.
if the project is...open source, we can have a try too...
Xeno Amess <xe...@gmail.com> 于2025年5月28日周三 17:09写道：
> @Sergey Chernov <se...@gmail.com>
> could you please give a link about the test suites you be using
>
> Sergey Chernov <se...@gmail.com> 于2025年5月27日周二 04:56写道：
>
>> Just tried the 4.0.0-rc-3 comparing with 3.9.9, it's 4x times slower (!)
>> on
>> a project of ~900 modules (700 of them are jar).
>> Maven 3 builds it in 2m57s, while Maven 4 in 11m48s (reproducible, with
>> all
>> m2 caches). No build cache solutions enabled to compare pure build time.
>> Project is nothing special, just java 17 + kotlin 2.1 compilation (no test
>> execution).
>> It fits into the same heap memory. The CPU cores load is about the same
>> (but 4x longer).
>> It seems that somewhere there is a huge overhead.
>>
>> Were there other performance tests at scale?
>>
>>
>> On Mon, May 26, 2025 at 4:48 PM Maarten Mulders <mt...@apache.org>
>> wrote:
>>
>> > Totally agree! I'm not trying to advocate "no more RC's", I'm trying to
>> > advocate "last RC should be as close as possible to the final product".
>> > And given what has happened between the last RC and today, I don't think
>> > we can cut 4.0.0 *today*. The diff is quite large IMO.
>> >
>> > Thanks,
>> >
>> >
>> > Maarten
>> >
>> > On May 26th, 2025 at 16:39, Elliotte Rusty Harold wrote:
>> > > On Mon, May 26, 2025 at 2:25 PM Maarten Mulders <
>> mthmulders@apache.org>
>> > wrote:
>> > >>
>> > >> That definition makes a lot of sense to me. If we would adhere to
>> it, we
>> > >> should discipline ourselves after "a" next RC and *not* accept any
>> code
>> > >> changes *except* for fixing critical uses.
>> > >
>> > > Be careful not to let the tail wag the dog. if changes are needed,
>> > > they're needed. You just need another RC. I would actually prefer that
>> > > RCs be identical to the release aside from version number, or even
>> > > better that the release candidate binary could simply become the
>> > > release, but that's not really how the Maven release process works.
>> > > However, critical bug fixes should generate a new RC. Overall I would
>> > > prefer much more rigorous versioning. Right now we're pushing RCs with
>> > > known unstable APIs, which I would normally consider appropriate for
>> > > pre-alpha builds.
>> > >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>>
>
Re: Maven 4.0.0 Release - Thoughts?
Posted by Xeno Amess <xe...@gmail.com>.
@Sergey Chernov <se...@gmail.com>
could you please give a link about the test suites you be using
Sergey Chernov <se...@gmail.com> 于2025年5月27日周二 04:56写道：
> Just tried the 4.0.0-rc-3 comparing with 3.9.9, it's 4x times slower (!) on
> a project of ~900 modules (700 of them are jar).
> Maven 3 builds it in 2m57s, while Maven 4 in 11m48s (reproducible, with all
> m2 caches). No build cache solutions enabled to compare pure build time.
> Project is nothing special, just java 17 + kotlin 2.1 compilation (no test
> execution).
> It fits into the same heap memory. The CPU cores load is about the same
> (but 4x longer).
> It seems that somewhere there is a huge overhead.
>
> Were there other performance tests at scale?
>
>
> On Mon, May 26, 2025 at 4:48 PM Maarten Mulders <mt...@apache.org>
> wrote:
>
> > Totally agree! I'm not trying to advocate "no more RC's", I'm trying to
> > advocate "last RC should be as close as possible to the final product".
> > And given what has happened between the last RC and today, I don't think
> > we can cut 4.0.0 *today*. The diff is quite large IMO.
> >
> > Thanks,
> >
> >
> > Maarten
> >
> > On May 26th, 2025 at 16:39, Elliotte Rusty Harold wrote:
> > > On Mon, May 26, 2025 at 2:25 PM Maarten Mulders <mthmulders@apache.org
> >
> > wrote:
> > >>
> > >> That definition makes a lot of sense to me. If we would adhere to it,
> we
> > >> should discipline ourselves after "a" next RC and *not* accept any
> code
> > >> changes *except* for fixing critical uses.
> > >
> > > Be careful not to let the tail wag the dog. if changes are needed,
> > > they're needed. You just need another RC. I would actually prefer that
> > > RCs be identical to the release aside from version number, or even
> > > better that the release candidate binary could simply become the
> > > release, but that's not really how the Maven release process works.
> > > However, critical bug fixes should generate a new RC. Overall I would
> > > prefer much more rigorous versioning. Right now we're pushing RCs with
> > > known unstable APIs, which I would normally consider appropriate for
> > > pre-alpha builds.
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Maven 4.0.0 Release - Thoughts?
Posted by Sergey Chernov <se...@gmail.com>.
That's interesting. I can try to inspect this with a profiler to find "hot"
stack traces.
On Tue, May 27, 2025 at 9:52 PM Martin Desruisseaux <
martin.desruisseaux@geomatys.com> wrote:
> Hello
>
> Le 2025-05-26 à 22 h 55, Sergey Chernov a écrit :
>
> > Just tried the 4.0.0-rc-3 comparing with 3.9.9, it's 4x times slower
> > (!) on a project of ~900 modules (700 of them are jar).
> >
> Regarding performance, some months ago I noticed that Maven contains
> loops over elements of a list with a call to `List.contains(…)` inside
> the loop. Because `List.contains(…)` itself iterates over the elements,
> we implicitly have nested loops, which have a performance cost of O(N²)
> where N is the number of elements. Replacing some `ArrayList` by
> `LinkedHashMap` may change some O(N²) operations into O(N) operations.
> The difference between O(N) and O(N²) is unnoticeable when N is small (I
> guess that this is the case of Maven's test suite). But when N become
> large enough, the difference between O(N) or O(N²) can become the
> difference between completing an operation in a few minutes or requiring
> the age of the univers.
>
> I did not verified if Maven 4 has more nested loops than Maven 3.
> Neither I verified if the nested loops happen in algorithms where N can
> possibly be large. We do not need (neither we should) replace all
> `ArrayList` by `LinkedHashMap`. However, I'm not sure if we have
> investigated where such replacements should be done. We may not be able
> to do this investigation now, but we could keep the door open for future
> performance improvements by replacing `List` by `Collection` in the API.
> Even if the implementation stay `ArrayList` for now, it would allow us
> to replace some of them by `LinkedHashMap` in the future if we identify
> that it could bring a performance benefit.
>
> However, an objection to this proposal was that the order of elements
> matter. We had no good solution in Java 17. But if the upgrade to Java
> 21, proposed in a separated thread, is accepted, Maven could replace all
> methods returning `java.util.List` by methods returning
> `java.util.SequencedCollection` in the API. No change in the
> implementation would be done at this stage (we keep the current
> `ArrayList`), but a future Maven version would have more flexibility for
> addressing the O(N²) kind of bottleneck, if any.
>
> Martin
>
>
Re: Maven 4.0.0 Release - Thoughts?
Posted by Xeno Amess <xe...@gmail.com>.
the biggest I found yet is https://github.com/apache/logging-log4j2.git
Xeno Amess <xe...@gmail.com> 于2025年5月28日周三 17:17写道：
> IMO LinkedHashSet can work, no need to use LinkedHashMap directly...
> but I still think it better to see the bottle-neck through real-world
> running. so let's just find some really biggy open source java projects
> using maven(if can't, maybe we have to craft one?)
>
>
> Martin Desruisseaux <ma...@geomatys.com> 于2025年5月28日周三
> 03:52写道：
>
>> Hello
>>
>> Le 2025-05-26 à 22 h 55, Sergey Chernov a écrit :
>>
>> > Just tried the 4.0.0-rc-3 comparing with 3.9.9, it's 4x times slower
>> > (!) on a project of ~900 modules (700 of them are jar).
>> >
>> Regarding performance, some months ago I noticed that Maven contains
>> loops over elements of a list with a call to `List.contains(…)` inside
>> the loop. Because `List.contains(…)` itself iterates over the elements,
>> we implicitly have nested loops, which have a performance cost of O(N²)
>> where N is the number of elements. Replacing some `ArrayList` by
>> `LinkedHashMap` may change some O(N²) operations into O(N) operations.
>> The difference between O(N) and O(N²) is unnoticeable when N is small (I
>> guess that this is the case of Maven's test suite). But when N become
>> large enough, the difference between O(N) or O(N²) can become the
>> difference between completing an operation in a few minutes or requiring
>> the age of the univers.
>>
>> I did not verified if Maven 4 has more nested loops than Maven 3.
>> Neither I verified if the nested loops happen in algorithms where N can
>> possibly be large. We do not need (neither we should) replace all
>> `ArrayList` by `LinkedHashMap`. However, I'm not sure if we have
>> investigated where such replacements should be done. We may not be able
>> to do this investigation now, but we could keep the door open for future
>> performance improvements by replacing `List` by `Collection` in the API.
>> Even if the implementation stay `ArrayList` for now, it would allow us
>> to replace some of them by `LinkedHashMap` in the future if we identify
>> that it could bring a performance benefit.
>>
>> However, an objection to this proposal was that the order of elements
>> matter. We had no good solution in Java 17. But if the upgrade to Java
>> 21, proposed in a separated thread, is accepted, Maven could replace all
>> methods returning `java.util.List` by methods returning
>> `java.util.SequencedCollection` in the API. No change in the
>> implementation would be done at this stage (we keep the current
>> `ArrayList`), but a future Maven version would have more flexibility for
>> addressing the O(N²) kind of bottleneck, if any.
>>
>> Martin
>>
>>
Re: Maven 4.0.0 Release - Thoughts?
Posted by Xeno Amess <xe...@gmail.com>.
IMO LinkedHashSet can work, no need to use LinkedHashMap directly...
but I still think it better to see the bottle-neck through real-world
running. so let's just find some really biggy open source java projects
using maven(if can't, maybe we have to craft one?)
Martin Desruisseaux <ma...@geomatys.com> 于2025年5月28日周三
03:52写道：
> Hello
>
> Le 2025-05-26 à 22 h 55, Sergey Chernov a écrit :
>
> > Just tried the 4.0.0-rc-3 comparing with 3.9.9, it's 4x times slower
> > (!) on a project of ~900 modules (700 of them are jar).
> >
> Regarding performance, some months ago I noticed that Maven contains
> loops over elements of a list with a call to `List.contains(…)` inside
> the loop. Because `List.contains(…)` itself iterates over the elements,
> we implicitly have nested loops, which have a performance cost of O(N²)
> where N is the number of elements. Replacing some `ArrayList` by
> `LinkedHashMap` may change some O(N²) operations into O(N) operations.
> The difference between O(N) and O(N²) is unnoticeable when N is small (I
> guess that this is the case of Maven's test suite). But when N become
> large enough, the difference between O(N) or O(N²) can become the
> difference between completing an operation in a few minutes or requiring
> the age of the univers.
>
> I did not verified if Maven 4 has more nested loops than Maven 3.
> Neither I verified if the nested loops happen in algorithms where N can
> possibly be large. We do not need (neither we should) replace all
> `ArrayList` by `LinkedHashMap`. However, I'm not sure if we have
> investigated where such replacements should be done. We may not be able
> to do this investigation now, but we could keep the door open for future
> performance improvements by replacing `List` by `Collection` in the API.
> Even if the implementation stay `ArrayList` for now, it would allow us
> to replace some of them by `LinkedHashMap` in the future if we identify
> that it could bring a performance benefit.
>
> However, an objection to this proposal was that the order of elements
> matter. We had no good solution in Java 17. But if the upgrade to Java
> 21, proposed in a separated thread, is accepted, Maven could replace all
> methods returning `java.util.List` by methods returning
> `java.util.SequencedCollection` in the API. No change in the
> implementation would be done at this stage (we keep the current
> `ArrayList`), but a future Maven version would have more flexibility for
> addressing the O(N²) kind of bottleneck, if any.
>
> Martin
>
>
Re: Maven 4.0.0 Release - Thoughts?
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Hello
Le 2025-05-26 à 22 h 55, Sergey Chernov a écrit :
> Just tried the 4.0.0-rc-3 comparing with 3.9.9, it's 4x times slower
> (!) on a project of ~900 modules (700 of them are jar).
>
Regarding performance, some months ago I noticed that Maven contains
loops over elements of a list with a call to `List.contains(…)` inside
the loop. Because `List.contains(…)` itself iterates over the elements,
we implicitly have nested loops, which have a performance cost of O(N²)
where N is the number of elements. Replacing some `ArrayList` by
`LinkedHashMap` may change some O(N²) operations into O(N) operations.
The difference between O(N) and O(N²) is unnoticeable when N is small (I
guess that this is the case of Maven's test suite). But when N become
large enough, the difference between O(N) or O(N²) can become the
difference between completing an operation in a few minutes or requiring
the age of the univers.
I did not verified if Maven 4 has more nested loops than Maven 3.
Neither I verified if the nested loops happen in algorithms where N can
possibly be large. We do not need (neither we should) replace all
`ArrayList` by `LinkedHashMap`. However, I'm not sure if we have
investigated where such replacements should be done. We may not be able
to do this investigation now, but we could keep the door open for future
performance improvements by replacing `List` by `Collection` in the API.
Even if the implementation stay `ArrayList` for now, it would allow us
to replace some of them by `LinkedHashMap` in the future if we identify
that it could bring a performance benefit.
However, an objection to this proposal was that the order of elements
matter. We had no good solution in Java 17. But if the upgrade to Java
21, proposed in a separated thread, is accepted, Maven could replace all
methods returning `java.util.List` by methods returning
`java.util.SequencedCollection` in the API. No change in the
implementation would be done at this stage (we keep the current
`ArrayList`), but a future Maven version would have more flexibility for
addressing the O(N²) kind of bottleneck, if any.
Martin
Re: Maven 4.0.0 Release - Thoughts?
Posted by Sergey Chernov <se...@gmail.com>.
Just tried the 4.0.0-rc-3 comparing with 3.9.9, it's 4x times slower (!) on
a project of ~900 modules (700 of them are jar).
Maven 3 builds it in 2m57s, while Maven 4 in 11m48s (reproducible, with all
m2 caches). No build cache solutions enabled to compare pure build time.
Project is nothing special, just java 17 + kotlin 2.1 compilation (no test
execution).
It fits into the same heap memory. The CPU cores load is about the same
(but 4x longer).
It seems that somewhere there is a huge overhead.
Were there other performance tests at scale?
On Mon, May 26, 2025 at 4:48 PM Maarten Mulders <mt...@apache.org>
wrote:
> Totally agree! I'm not trying to advocate "no more RC's", I'm trying to
> advocate "last RC should be as close as possible to the final product".
> And given what has happened between the last RC and today, I don't think
> we can cut 4.0.0 *today*. The diff is quite large IMO.
>
> Thanks,
>
>
> Maarten
>
> On May 26th, 2025 at 16:39, Elliotte Rusty Harold wrote:
> > On Mon, May 26, 2025 at 2:25 PM Maarten Mulders <mt...@apache.org>
> wrote:
> >>
> >> That definition makes a lot of sense to me. If we would adhere to it, we
> >> should discipline ourselves after "a" next RC and *not* accept any code
> >> changes *except* for fixing critical uses.
> >
> > Be careful not to let the tail wag the dog. if changes are needed,
> > they're needed. You just need another RC. I would actually prefer that
> > RCs be identical to the release aside from version number, or even
> > better that the release candidate binary could simply become the
> > release, but that's not really how the Maven release process works.
> > However, critical bug fixes should generate a new RC. Overall I would
> > prefer much more rigorous versioning. Right now we're pushing RCs with
> > known unstable APIs, which I would normally consider appropriate for
> > pre-alpha builds.
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven 4.0.0 Release - Thoughts?
Posted by Maarten Mulders <mt...@apache.org>.
Totally agree! I'm not trying to advocate "no more RC's", I'm trying to
advocate "last RC should be as close as possible to the final product".
And given what has happened between the last RC and today, I don't think
we can cut 4.0.0 *today*. The diff is quite large IMO.
Thanks,
Maarten
On May 26th, 2025 at 16:39, Elliotte Rusty Harold wrote:
> On Mon, May 26, 2025 at 2:25 PM Maarten Mulders <mt...@apache.org> wrote:
>>
>> That definition makes a lot of sense to me. If we would adhere to it, we
>> should discipline ourselves after "a" next RC and *not* accept any code
>> changes *except* for fixing critical uses.
>
> Be careful not to let the tail wag the dog. if changes are needed,
> they're needed. You just need another RC. I would actually prefer that
> RCs be identical to the release aside from version number, or even
> better that the release candidate binary could simply become the
> release, but that's not really how the Maven release process works.
> However, critical bug fixes should generate a new RC. Overall I would
> prefer much more rigorous versioning. Right now we're pushing RCs with
> known unstable APIs, which I would normally consider appropriate for
> pre-alpha builds.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0 Release - Thoughts?
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Mon, May 26, 2025 at 2:25 PM Maarten Mulders <mt...@apache.org> wrote:
>
> That definition makes a lot of sense to me. If we would adhere to it, we
> should discipline ourselves after "a" next RC and *not* accept any code
> changes *except* for fixing critical uses.
Be careful not to let the tail wag the dog. if changes are needed,
they're needed. You just need another RC. I would actually prefer that
RCs be identical to the release aside from version number, or even
better that the release candidate binary could simply become the
release, but that's not really how the Maven release process works.
However, critical bug fixes should generate a new RC. Overall I would
prefer much more rigorous versioning. Right now we're pushing RCs with
known unstable APIs, which I would normally consider appropriate for
pre-alpha builds.
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0 Release - Thoughts?
Posted by Maarten Mulders <mt...@apache.org>.
That definition makes a lot of sense to me. If we would adhere to it, we
should discipline ourselves after "a" next RC and *not* accept any code
changes *except* for fixing critical uses.
I think there have been too many changes since last RC to cut a 4.0.0 today.
Maarten
On 26/05/2025 14:14, Nikita Skvortsov wrote:
> I believe having a "Release Candidate" is a good idea
>
> As long as it is indeed a candidate: a version that is exactly the same as
> a release, except for discovered critical issues and version numbers.
> I wonder if promoting a candidate to a GA without any code changes requires
> modification of existing community processes.
>
> ---
> Nikita Skvortsov
> Java Build Tools Team Lead
>
> JetBrains N.V. | KvK reg. nr. 56460279
> Gelrestraat 16, 1079 MZ Amsterdam, The Netherlands
> T: + 31 (0)20 205 01 18 | F: +31 (0)20 205 01 19
> E: Nikita.Skvortsov@jetbrains.com
>
>
> On Sat, 24 May 2025 at 11:12, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
>> Do we have the list of planned API changes?
>> Most changes can likely be limited using a "request/response object"
>> pattern (so we can add data without breaking instead of passing N
>> parameters), new methods dont break, so ultimately we are not worse than
>> 3.9.x in terms of stability if we respect that or do respect that in the
>> future.
>>
>> My point is that we can say the exact same reasons to never release v4
>> whereas it is adopted by several people since months now so we should let
>> it go and handle bugs as bugs and not as RC which doesnt mean anything
>> anymore IMHO.
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://x.com/rmannibucau> | .NET Blog
>> <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/>
>> | Old
>> Blog <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Book
>> <
>> https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064
>>>
>>
>>
>> Le ven. 23 mai 2025 à 19:32, Benjamin Marwell <bm...@apache.org> a
>> écrit :
>>
>>> -1 for release, +1 for rc4.
>>> Reason: What Sylwester said, plus Nikita from JetBrains asking nicely.
>>> They (JB) would love to see API stability so they can ship an IntelliJ
>>> IDEA release in time with Maven 4.
>>> This of course applies to all other IDEs.
>>>
>>> Nikita is on #maven in slack, maybe also subscribed here? idk.
>>>
>>> Anyway, really strong reasons to do an RC4 first.
>>> This should not be hasted.
>>>
>>> - Ben
>>>
>>> Am Fr., 23. Mai 2025 um 00:05 Uhr schrieb Sylwester Lachiewicz
>>> <sl...@gmail.com>:
>>>>
>>>> I would go for rc4 because we still have API changes after rc3 and our
>>>> plugins needs adjustments that could again require another, smaller
>>>> changes.
>>>> With current state of plugins 4.x they can't be used with latest
>> (master)
>>>> version so we could offer only 3.x for Maven 4.
>>>> Not so big issue for many users but without semi automatic way to move
>>>> plugin to new public API we are selling new "untested internally".
>>>>
>>>> In my opinion, if we could have releases of core plugins based on rc4
>> API
>>>> and our CI/CD pipelines runs also under Maven 4 - it would be safer.
>>>>
>>>> Sylwester
>>>>
>>>> śr., 21 maj 2025, 08:12 użytkownik Guillaume Nodet <gn...@apache.org>
>>>> napisał:
>>>>
>>>>> Hey Maven Devs,
>>>>>
>>>>> We're gearing up to release a new version from the master branch. I'm
>>>>> thinking we should go for 4.0.0 instead of rc-4. What do you all
>>> think? Any
>>>>> feedback or ideas on the versioning or release plan? Let’s hear it!
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Guillaume
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0 Release - Thoughts?
Posted by Nikita Skvortsov <ni...@jetbrains.com.INVALID>.
I believe having a "Release Candidate" is a good idea
As long as it is indeed a candidate: a version that is exactly the same as
a release, except for discovered critical issues and version numbers.
I wonder if promoting a candidate to a GA without any code changes requires
modification of existing community processes.
---
Nikita Skvortsov
Java Build Tools Team Lead
JetBrains N.V. | KvK reg. nr. 56460279
Gelrestraat 16, 1079 MZ Amsterdam, The Netherlands
T: + 31 (0)20 205 01 18 | F: +31 (0)20 205 01 19
E: Nikita.Skvortsov@jetbrains.com
On Sat, 24 May 2025 at 11:12, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Do we have the list of planned API changes?
> Most changes can likely be limited using a "request/response object"
> pattern (so we can add data without breaking instead of passing N
> parameters), new methods dont break, so ultimately we are not worse than
> 3.9.x in terms of stability if we respect that or do respect that in the
> future.
>
> My point is that we can say the exact same reasons to never release v4
> whereas it is adopted by several people since months now so we should let
> it go and handle bugs as bugs and not as RC which doesnt mean anything
> anymore IMHO.
>
> Romain Manni-Bucau
> @rmannibucau <https://x.com/rmannibucau> | .NET Blog
> <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/>
> | Old
> Blog <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064
> >
>
>
> Le ven. 23 mai 2025 à 19:32, Benjamin Marwell <bm...@apache.org> a
> écrit :
>
> > -1 for release, +1 for rc4.
> > Reason: What Sylwester said, plus Nikita from JetBrains asking nicely.
> > They (JB) would love to see API stability so they can ship an IntelliJ
> > IDEA release in time with Maven 4.
> > This of course applies to all other IDEs.
> >
> > Nikita is on #maven in slack, maybe also subscribed here? idk.
> >
> > Anyway, really strong reasons to do an RC4 first.
> > This should not be hasted.
> >
> > - Ben
> >
> > Am Fr., 23. Mai 2025 um 00:05 Uhr schrieb Sylwester Lachiewicz
> > <sl...@gmail.com>:
> > >
> > > I would go for rc4 because we still have API changes after rc3 and our
> > > plugins needs adjustments that could again require another, smaller
> > > changes.
> > > With current state of plugins 4.x they can't be used with latest
> (master)
> > > version so we could offer only 3.x for Maven 4.
> > > Not so big issue for many users but without semi automatic way to move
> > > plugin to new public API we are selling new "untested internally".
> > >
> > > In my opinion, if we could have releases of core plugins based on rc4
> API
> > > and our CI/CD pipelines runs also under Maven 4 - it would be safer.
> > >
> > > Sylwester
> > >
> > > śr., 21 maj 2025, 08:12 użytkownik Guillaume Nodet <gn...@apache.org>
> > > napisał:
> > >
> > > > Hey Maven Devs,
> > > >
> > > > We're gearing up to release a new version from the master branch. I'm
> > > > thinking we should go for 4.0.0 instead of rc-4. What do you all
> > think? Any
> > > > feedback or ideas on the versioning or release plan? Let’s hear it!
> > > >
> > > > Cheers,
> > > >
> > > > Guillaume
> > > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Maven 4.0.0 Release - Thoughts?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Do we have the list of planned API changes?
Most changes can likely be limited using a "request/response object"
pattern (so we can add data without breaking instead of passing N
parameters), new methods dont break, so ultimately we are not worse than
3.9.x in terms of stability if we respect that or do respect that in the
future.
My point is that we can say the exact same reasons to never release v4
whereas it is adopted by several people since months now so we should let
it go and handle bugs as bugs and not as RC which doesnt mean anything
anymore IMHO.
Romain Manni-Bucau
@rmannibucau <https://x.com/rmannibucau> | .NET Blog
<https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old
Blog <http://rmannibucau.wordpress.com> | Github
<https://github.com/rmannibucau> | LinkedIn
<https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064>
Le ven. 23 mai 2025 à 19:32, Benjamin Marwell <bm...@apache.org> a
écrit :
> -1 for release, +1 for rc4.
> Reason: What Sylwester said, plus Nikita from JetBrains asking nicely.
> They (JB) would love to see API stability so they can ship an IntelliJ
> IDEA release in time with Maven 4.
> This of course applies to all other IDEs.
>
> Nikita is on #maven in slack, maybe also subscribed here? idk.
>
> Anyway, really strong reasons to do an RC4 first.
> This should not be hasted.
>
> - Ben
>
> Am Fr., 23. Mai 2025 um 00:05 Uhr schrieb Sylwester Lachiewicz
> <sl...@gmail.com>:
> >
> > I would go for rc4 because we still have API changes after rc3 and our
> > plugins needs adjustments that could again require another, smaller
> > changes.
> > With current state of plugins 4.x they can't be used with latest (master)
> > version so we could offer only 3.x for Maven 4.
> > Not so big issue for many users but without semi automatic way to move
> > plugin to new public API we are selling new "untested internally".
> >
> > In my opinion, if we could have releases of core plugins based on rc4 API
> > and our CI/CD pipelines runs also under Maven 4 - it would be safer.
> >
> > Sylwester
> >
> > śr., 21 maj 2025, 08:12 użytkownik Guillaume Nodet <gn...@apache.org>
> > napisał:
> >
> > > Hey Maven Devs,
> > >
> > > We're gearing up to release a new version from the master branch. I'm
> > > thinking we should go for 4.0.0 instead of rc-4. What do you all
> think? Any
> > > feedback or ideas on the versioning or release plan? Let’s hear it!
> > >
> > > Cheers,
> > >
> > > Guillaume
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven 4.0.0 Release - Thoughts?
Posted by Benjamin Marwell <bm...@apache.org>.
-1 for release, +1 for rc4.
Reason: What Sylwester said, plus Nikita from JetBrains asking nicely.
They (JB) would love to see API stability so they can ship an IntelliJ
IDEA release in time with Maven 4.
This of course applies to all other IDEs.
Nikita is on #maven in slack, maybe also subscribed here? idk.
Anyway, really strong reasons to do an RC4 first.
This should not be hasted.
- Ben
Am Fr., 23. Mai 2025 um 00:05 Uhr schrieb Sylwester Lachiewicz
<sl...@gmail.com>:
>
> I would go for rc4 because we still have API changes after rc3 and our
> plugins needs adjustments that could again require another, smaller
> changes.
> With current state of plugins 4.x they can't be used with latest (master)
> version so we could offer only 3.x for Maven 4.
> Not so big issue for many users but without semi automatic way to move
> plugin to new public API we are selling new "untested internally".
>
> In my opinion, if we could have releases of core plugins based on rc4 API
> and our CI/CD pipelines runs also under Maven 4 - it would be safer.
>
> Sylwester
>
> śr., 21 maj 2025, 08:12 użytkownik Guillaume Nodet <gn...@apache.org>
> napisał:
>
> > Hey Maven Devs,
> >
> > We're gearing up to release a new version from the master branch. I'm
> > thinking we should go for 4.0.0 instead of rc-4. What do you all think? Any
> > feedback or ideas on the versioning or release plan? Let’s hear it!
> >
> > Cheers,
> >
> > Guillaume
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0 Release - Thoughts?
Posted by Sylwester Lachiewicz <sl...@gmail.com>.
I would go for rc4 because we still have API changes after rc3 and our
plugins needs adjustments that could again require another, smaller
changes.
With current state of plugins 4.x they can't be used with latest (master)
version so we could offer only 3.x for Maven 4.
Not so big issue for many users but without semi automatic way to move
plugin to new public API we are selling new "untested internally".
In my opinion, if we could have releases of core plugins based on rc4 API
and our CI/CD pipelines runs also under Maven 4 - it would be safer.
Sylwester
śr., 21 maj 2025, 08:12 użytkownik Guillaume Nodet <gn...@apache.org>
napisał:
> Hey Maven Devs,
>
> We're gearing up to release a new version from the master branch. I'm
> thinking we should go for 4.0.0 instead of rc-4. What do you all think? Any
> feedback or ideas on the versioning or release plan? Let’s hear it!
>
> Cheers,
>
> Guillaume
>
Re: Maven 4.0.0 Release - Thoughts?
Posted by Michael Osipov <mi...@apache.org>.
On 2025/05/21 09:05:07 Guillaume Nodet wrote:
> Hi all,
>
> I have several significant features waiting as PRs (mixins and
> cascading profiles), but I’ve decided to postpone them until 4.1.0.
> For what it’s worth, several people, including the IntelliJ team, have
> expressed concerns about 4.0.0 being a moving target due to the
> continuous addition of new features in RCs.
This is fine.
> I’d prefer to release 4.0.0 with a limited set of new features to
> ensure stability and reserve the larger changes for 4.1.0, which we
> could target for the end of year. This could also include the upgrade
> to JDK 21 since JDK 25 should be released in September.
OK as well to push to 4.1.0, but raising requirements is another discussion.
> Best,
> Guillaume Nodet
>
> Le mer. 21 mai 2025 à 10:13, Michael Osipov <mi...@apache.org> a écrit :
> >
> > On 2025/05/21 06:11:42 Guillaume Nodet wrote:
> > > Hey Maven Devs,
> > >
> > > We're gearing up to release a new version from the master branch. I'm
> > > thinking we should go for 4.0.0 instead of rc-4. What do you all think? Any
> > > feedback or ideas on the versioning or release plan? Let’s hear it!
> >
> > Slawek is working on a bigger new feature which deserves another RC...
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
> --
> ------------------------
> Guillaume Nodet
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0 Release - Thoughts?
Posted by Hervé Boutemy <hb...@apache.org>.
Le jeudi 22 mai 2025, 08:49:20 CEST Mark Derricutt a écrit :
> On 22 May 2025 at 6:19:26 PM, Hervé Boutemy <hb...@apache.org> wrote:
> > I don't get what plugin updates are expected: are there Maven 3 plugins
> > known
> > to fail on Maven 4? If yes, are they so many?
>
> That I’m not sure - since we can’t run our builds under Maven 4 (tiles,
> mixins, the problems of my ownn makings) I’ve not really tried M4 outside
> of small projects.
>
> I should check the OSGi bundle-maven-plugin along with the ANTLR plugins we
> use.
we'll probably need to clearly track somewhere
I absolutely want to avoid the masses to feel they are forced to maintain a
Maven 4-specific plugin fork: Maven 4 API is the future, yes, but the path is
expected to be smooth with Maven 3 plugin API compatibility
= that's the intent AFAIK: I hope the actual result will match the intent
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0 Release - Thoughts?
Posted by Mark Derricutt <ma...@talios.com>.
On 22 May 2025 at 6:19:26 PM, Hervé Boutemy <hb...@apache.org> wrote:
> I don't get what plugin updates are expected: are there Maven 3 plugins
> known
> to fail on Maven 4? If yes, are they so many?
>
That I’m not sure - since we can’t run our builds under Maven 4 (tiles,
mixins, the problems of my ownn makings) I’ve not really tried M4 outside
of small projects.
I should check the OSGi bundle-maven-plugin along with the ANTLR plugins we
use.
--
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree
Re: Maven 4.0.0 Release - Thoughts?
Posted by Hervé Boutemy <hb...@apache.org>.
+1 we need a release before adding new changes
> world as well - or more than likely, a raft of third-party plugin updates.
I don't get what plugin updates are expected: are there Maven 3 plugins known
to fail on Maven 4? If yes, are they so many?
I hope releasing Maven 4 will help clarify
which plugins will continue to be maintained as Maven 3 plugins "just working
on Maven 4"
and which plugins will absolutely require to fork a Maven 4 branch from usual
Maven 3 one because it's not possible to keep it simple...
Regards,
Hervé
Le mercredi 21 mai 2025, 11:22:08 CEST Mark Derricutt a écrit :
> On 21 May 2025 at 9:05:07 PM, Guillaume Nodet <gn...@apache.org> wrote:
>
> I’d prefer to release 4.0.0 with a limited set of new features to
>
> > ensure stability and reserve the larger changes for 4.1.0, which we
> > could target for the end of year. This could also include the upgrade
> > to JDK 21 since JDK 25 should be released in September.
>
> As much as I keen on mixins as I won’t be able to actually use 4.0.0, I’d
> down for seeing 4 get out sooner rather than later. If that helps Jetbrains
> and other IDE tool vendors a stable version to work with, that’ll help with
> wider adoption and upgrades.
>
> I suspect there might be a need for a 4.0.1 etc. once it hits the wider
> world as well - or more than likely, a raft of third-party plugin updates.
>
> Mark.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0 Release - Thoughts?
Posted by Henning Schmiedehausen <he...@schmiedehausen.org.INVALID>.
Big +1 to that. The maven 4 cycle has stretched for a long time and having
an actual release which can be targeted by the tool vendors would be a
great thing.
-h
On Wed, May 21, 2025 at 2:05 AM Guillaume Nodet <gn...@apache.org> wrote:
> Hi all,
>
> I have several significant features waiting as PRs (mixins and
> cascading profiles), but I’ve decided to postpone them until 4.1.0.
> For what it’s worth, several people, including the IntelliJ team, have
> expressed concerns about 4.0.0 being a moving target due to the
> continuous addition of new features in RCs.
>
> I’d prefer to release 4.0.0 with a limited set of new features to
> ensure stability and reserve the larger changes for 4.1.0, which we
> could target for the end of year. This could also include the upgrade
> to JDK 21 since JDK 25 should be released in September.
>
> What are your thoughts on this approach?
>
> Best,
> Guillaume Nodet
>
> Le mer. 21 mai 2025 à 10:13, Michael Osipov <mi...@apache.org> a écrit
> :
> >
> > On 2025/05/21 06:11:42 Guillaume Nodet wrote:
> > > Hey Maven Devs,
> > >
> > > We're gearing up to release a new version from the master branch. I'm
> > > thinking we should go for 4.0.0 instead of rc-4. What do you all
> think? Any
> > > feedback or ideas on the versioning or release plan? Let’s hear it!
> >
> > Slawek is working on a bigger new feature which deserves another RC...
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
> --
> ------------------------
> Guillaume Nodet
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven 4.0.0 Release - Thoughts?
Posted by Mark Derricutt <ma...@talios.com>.
On 21 May 2025 at 9:05:07 PM, Guillaume Nodet <gn...@apache.org> wrote:
I’d prefer to release 4.0.0 with a limited set of new features to
> ensure stability and reserve the larger changes for 4.1.0, which we
> could target for the end of year. This could also include the upgrade
> to JDK 21 since JDK 25 should be released in September.
>
>
As much as I keen on mixins as I won’t be able to actually use 4.0.0, I’d
down for seeing 4 get out sooner rather than later. If that helps Jetbrains
and other IDE tool vendors a stable version to work with, that’ll help with
wider adoption and upgrades.
I suspect there might be a need for a 4.0.1 etc. once it hits the wider
world as well - or more than likely, a raft of third-party plugin updates.
Mark.
Re: Maven 4.0.0 Release - Thoughts?
Posted by Guillaume Nodet <gn...@apache.org>.
Hi all,
I have several significant features waiting as PRs (mixins and
cascading profiles), but I’ve decided to postpone them until 4.1.0.
For what it’s worth, several people, including the IntelliJ team, have
expressed concerns about 4.0.0 being a moving target due to the
continuous addition of new features in RCs.
I’d prefer to release 4.0.0 with a limited set of new features to
ensure stability and reserve the larger changes for 4.1.0, which we
could target for the end of year. This could also include the upgrade
to JDK 21 since JDK 25 should be released in September.
What are your thoughts on this approach?
Best,
Guillaume Nodet
Le mer. 21 mai 2025 à 10:13, Michael Osipov <mi...@apache.org> a écrit :
>
> On 2025/05/21 06:11:42 Guillaume Nodet wrote:
> > Hey Maven Devs,
> >
> > We're gearing up to release a new version from the master branch. I'm
> > thinking we should go for 4.0.0 instead of rc-4. What do you all think? Any
> > feedback or ideas on the versioning or release plan? Let’s hear it!
>
> Slawek is working on a bigger new feature which deserves another RC...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
------------------------
Guillaume Nodet
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0 Release - Thoughts?
Posted by Michael Osipov <mi...@apache.org>.
On 2025/05/21 06:11:42 Guillaume Nodet wrote:
> Hey Maven Devs,
>
> We're gearing up to release a new version from the master branch. I'm
> thinking we should go for 4.0.0 instead of rc-4. What do you all think? Any
> feedback or ideas on the versioning or release plan? Let’s hear it!
Slawek is working on a bigger new feature which deserves another RC...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0 Release - Thoughts?
Posted by Gary Gregory <ga...@gmail.com>.
Jetty is a good one as well: https://github.com/jetty/jetty.project
Gary
On Wed, May 28, 2025, 08:55 Sergey Chernov <se...@gmail.com> wrote:
> Guillaume, that's awesome. It's good that there is no rush with it.
> Once I'll have insights, I'll share them.
>
> Xeno, the project I'm checking is private unfortunately. Also this can be
> quite challenging to find a good Maven multi-module project as a reference
> for performance testing and compatibility validations, as many of big
> projects e.g. have flaky tests and other issues.
> Some of the biggest that I've seen:
> * https://github.com/quarkusio/quarkus (has lots of customizations in
> .mvn/extensions.xml)
> * https://github.com/apache/dubbo
> * https://github.com/apache/hadoop
> * https://github.com/apache/struts
> * https://github.com/vaadin/flow and https://github.com/vaadin/framework
>
>
> On Wed, May 28, 2025 at 2:16 PM Guillaume Nodet <gn...@apache.org> wrote:
>
> > After considering the concerns about API stability, plugin
> > compatibility, and the performance issues reported by Sergey (4x
> > slower in rc3), I agree with Sylwester, Benjamin, and Elliotte that we
> > should opt for an rc4 to address these issues. My proposal is to
> > release a final release candidate (rc4) soon, aiming for a General
> > Availability (GA) release in September. Post rc4, I suggest creating a
> > 4.0.x branch to start work on 4.1.0. For 4.1.0, we could introduce API
> > changes like records and sequenced collections, as well as new
> > features such as mixins, cascading profiles, server aliases, JDK 21
> > (still under discussion) and more....
> >
> > The recent API changes for JPMS, as Martin noted, only affect the
> > experimental API, so they shouldn’t block the release. On Matthias’s
> > suggestion, enabling GitHub Issues across all repositories before the
> > GA seems like a good idea to improve user feedback. Let’s focus on
> > stabilizing rc4 and addressing performance bottlenecks, possibly
> > exploring Martin’s O(N²) concerns with profiling, as Sergey offered.
> >
> > What do you think about this plan?
> >
> > On a side note, I created a few months ago a project to check Maven 4
> > compatibility with all Apache projects using Maven. The results for
> > RC-3 can be found at
> > https://github.com/gnodet/maven4-testing/issues/2812. Most of the
> > errors are caused by the use of incompatible plugins (which needs to
> > be updated) or incorrect POMs (as Maven 4 is more strict about a few
> > things). What would be nice is a tool to integrate in the shell that
> > would fix those known incompatibilities, so that users would have an
> > easier migration path. And we could apply it to this project to make
> > more green boxes.
> >
> > Le mer. 21 mai 2025 à 08:11, Guillaume Nodet <gn...@apache.org> a
> écrit :
> > >
> > > Hey Maven Devs,
> > >
> > > We're gearing up to release a new version from the master branch. I'm
> > thinking we should go for 4.0.0 instead of rc-4. What do you all think?
> Any
> > feedback or ideas on the versioning or release plan? Let’s hear it!
> > >
> > > Cheers,
> > >
> > > Guillaume
> > >
> > >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Investigate mvn4 large graph performance regression; was: Re: Maven 4.0.0 Release - Thoughts?
Posted by Xeno Amess <xe...@gmail.com>.
well I found the reason(s)!
I pushed several prs to maven and maven-resolver.
the final score is about 2/3 - 1/2 time usage than before the refining.
please have a look(especially the pr in maven-resolver, which is the most
severe one.).
Xeno Amess <xe...@gmail.com> 于2025年6月14日周六 14:54写道：
> Weather here is bad in my city...just suffering from typhoon days.
> I would give several pr about my investigations on Sergey Chernov's demo
> repo this weekend.
> Most of them be minor/medium level performance refinements.
>
Re: Investigate mvn4 large graph performance regression; was: Re: Maven 4.0.0 Release - Thoughts?
Posted by Xeno Amess <xe...@gmail.com>.
Weather here is bad in my city...just suffering from typhoon days.
I would give several pr about my investigations on Sergey Chernov's demo
repo this weekend.
Most of them be minor/medium level performance refinements.
Investigate mvn4 large graph performance regression; was: Re: Maven 4.0.0 Release - Thoughts?
Posted by Michael Bien <mb...@gmail.com>.
excellent!
looks like the hash code paths were only part of the puzzle.
I added some screenshots to this issue https://github.com/apache/maven/issues/2481, since it is easier to share graphs there compared to mail attachments.
unfortunately the weather is nice so I am not sure how much time I can spend on this the next days, but this doesn't look to me like a showstopper for mvn4 in my opinion (as user) since it can be likely improved via regular updates.
best regards,
michael
On 6/13/25 11:18, Sergey Chernov wrote:
> I made a simple multi-module project generator which has some size
> parameters.
> Please see project description here
> https://github.com/maven-turbo-reactor/maven-multiproject-generator
>
> The good news is that it highlights the performance problem in comparison
> between Maven3 and Maven4.
> The generated project (which has 4k modules with default config, but zero
> java source classes) takes 30sec on Maven3 and 1m40s on Maven4.
>
> I'd like to point that it also declares usage of maven-enforcer-plugin with
> this config:
> ```
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-enforcer-plugin</artifactId>
> <version>3.3.0</version>
> <executions>
> <execution>
> <id>enforce</id>
> <configuration>
> <rules>
> <DependencyConvergence>
> <uniqueVersions>false</uniqueVersions>
> </DependencyConvergence>
> </rules>
> </configuration>
> <goals>
> <goal>enforce</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
> ```
> This plugin was my main suspect for the slowness, but it seems that any
> plugin that iterates the dependencies (including any compilation plugin)
> are affecting performance on Maven4. If enforcer plugin is removed, the
> build is still slow on Maven4 (2.5x slower than Maven3).
>
> On Thu, Jun 12, 2025 at 1:33 PM Martijn Dashorst <ma...@gmail.com>
> wrote:
>
>> On Thu, Jun 12, 2025 at 1:48 AM Michael Bien <mb...@gmail.com> wrote:
>>
>>> If there is a public project which hits this bottleneck I could take a
>>> look and play
>>> with some ideas to try to make this scale better. (I don't really want to
>>> spam this thread
>>> too much)
>>>
>> You could take a look at https://github.com/wicketstuff/core
>>
>> Lots and lots of projects..
>>
>> Martijn
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0 Release - Thoughts?
Posted by Tamás Cservenák <ta...@cservenak.net>.
Coolio, kudos Sergey!
My numbers are (OS name: "linux", version: "6.14.9-300.fc42.x86_64",
arch: "amd64", family: "unix", Java version: 21.0.7, vendor: Eclipse
Adoptium):
mvn 3.9.10: 0:39
mvn4 master + R2.0.9: 1:36
mvn4 master + R2.0.10-SNAPSHOT: 1:42
The "R" is Resolver, and 2.0.10 contains this:
https://github.com/apache/maven-resolver/commit/93bd1cb084e756beb3e544d368afaf006082f557
https://github.com/apache/maven-resolver/commit/daff12619a5be961a5dad8c191a47edc4ec353c4
But it is not the culprit it seems.
Still, we now have a reproducer to work with, and MANY thanks for that!
Thanks
T
On Fri, Jun 13, 2025 at 11:19 AM Sergey Chernov <se...@gmail.com> wrote:
>
> I made a simple multi-module project generator which has some size
> parameters.
> Please see project description here
> https://github.com/maven-turbo-reactor/maven-multiproject-generator
>
> The good news is that it highlights the performance problem in comparison
> between Maven3 and Maven4.
> The generated project (which has 4k modules with default config, but zero
> java source classes) takes 30sec on Maven3 and 1m40s on Maven4.
>
> I'd like to point that it also declares usage of maven-enforcer-plugin with
> this config:
> ```
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-enforcer-plugin</artifactId>
> <version>3.3.0</version>
> <executions>
> <execution>
> <id>enforce</id>
> <configuration>
> <rules>
> <DependencyConvergence>
> <uniqueVersions>false</uniqueVersions>
> </DependencyConvergence>
> </rules>
> </configuration>
> <goals>
> <goal>enforce</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
> ```
> This plugin was my main suspect for the slowness, but it seems that any
> plugin that iterates the dependencies (including any compilation plugin)
> are affecting performance on Maven4. If enforcer plugin is removed, the
> build is still slow on Maven4 (2.5x slower than Maven3).
>
> On Thu, Jun 12, 2025 at 1:33 PM Martijn Dashorst <ma...@gmail.com>
> wrote:
>
> > On Thu, Jun 12, 2025 at 1:48 AM Michael Bien <mb...@gmail.com> wrote:
> >
> > > If there is a public project which hits this bottleneck I could take a
> > > look and play
> > > with some ideas to try to make this scale better. (I don't really want to
> > > spam this thread
> > > too much)
> > >
> >
> > You could take a look at https://github.com/wicketstuff/core
> >
> > Lots and lots of projects..
> >
> > Martijn
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0 Release - Thoughts?
Posted by Sergey Chernov <se...@gmail.com>.
I made a simple multi-module project generator which has some size
parameters.
Please see project description here
https://github.com/maven-turbo-reactor/maven-multiproject-generator
The good news is that it highlights the performance problem in comparison
between Maven3 and Maven4.
The generated project (which has 4k modules with default config, but zero
java source classes) takes 30sec on Maven3 and 1m40s on Maven4.
I'd like to point that it also declares usage of maven-enforcer-plugin with
this config:
```
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>3.3.0</version>
<executions>
<execution>
<id>enforce</id>
<configuration>
<rules>
<DependencyConvergence>
<uniqueVersions>false</uniqueVersions>
</DependencyConvergence>
</rules>
</configuration>
<goals>
<goal>enforce</goal>
</goals>
</execution>
</executions>
</plugin>
```
This plugin was my main suspect for the slowness, but it seems that any
plugin that iterates the dependencies (including any compilation plugin)
are affecting performance on Maven4. If enforcer plugin is removed, the
build is still slow on Maven4 (2.5x slower than Maven3).
On Thu, Jun 12, 2025 at 1:33 PM Martijn Dashorst <ma...@gmail.com>
wrote:
> On Thu, Jun 12, 2025 at 1:48 AM Michael Bien <mb...@gmail.com> wrote:
>
> > If there is a public project which hits this bottleneck I could take a
> > look and play
> > with some ideas to try to make this scale better. (I don't really want to
> > spam this thread
> > too much)
> >
>
> You could take a look at https://github.com/wicketstuff/core
>
> Lots and lots of projects..
>
> Martijn
>
Re: Maven 4.0.0 Release - Thoughts?
Posted by Martijn Dashorst <ma...@gmail.com>.
On Thu, Jun 12, 2025 at 1:48 AM Michael Bien <mb...@gmail.com> wrote:
> If there is a public project which hits this bottleneck I could take a
> look and play
> with some ideas to try to make this scale better. (I don't really want to
> spam this thread
> too much)
>
You could take a look at https://github.com/wicketstuff/core
Lots and lots of projects..
Martijn
Re: Maven 4.0.0 Release - Thoughts?
Posted by Michael Bien <mb...@gmail.com>.
On 6/11/25 08:54, Michael Bien wrote:
> Hi,
>
> 3/4 stack traces you posted contained the constructor frame with the Objects.hash() call.
>
> Hash code over so many collections can scale badly once the collections grow:
> https://github.com/apache/maven-resolver/blob/145588be6d5b2c0111b5f367787d4c9347c326da/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/manager/AbstractDependencyManager.java#L118-L126
>
> It will grab every key/value pair and call hashCode() on it to build the final value.
>
> If the dependency manager isn't put into Sets/Maps the hashcode could be potentially
> calculated lazily (which would ideally not compute it at all and avoid the problem).
> But I haven't looked at the code any deeper than that - maybe this isn't possible.
thats essentially what the 1.9.x impl did:
https://github.com/apache/maven-resolver/blob/8535d09660cb68eb55d8e75228d5d35eaae00c88/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/manager/TransitiveDependencyManager.java#L232-L237
Updating AbstractDependencyManager alone won't change much though
since the whole graph is computing the hash codes eagerly now - so it would
be called anyway just a little bit later.
If there is a public project which hits this bottleneck I could take a look and play
with some ideas to try to make this scale better. (I don't really want to spam this thread
too much)
best regards,
michael
>
> (as sidenote: managedLocalPaths is missing in equals)
>
>
>
> I do like using async-profiler* in situations like this since it is easy to use and
> the flame graphs often provide a good overview showing relative CPU usage. But in this
> case you likely already found the bottleneck in the stacktraces you took.
>
> usage would be:
>
> sudo sysctl kernel.kptr_restrict=0 && sudo sysctl kernel.perf_event_paranoid=1
>
> export MAVEN_OPTS=-agentpath:/path/to/async-profiler-4.0-linux-x64/lib/libasyncProfiler.so=start,event=cpu,file=maven.html
>
> run mvn command. Check maven.html.
>
>
> best regards,
> michael
>
>
> * https://github.com/async-profiler/async-profiler
>
>
> On 6/10/25 18:10, Sergey Chernov wrote:
>> I was able to run the Maven build (~900 modules) with the profiler.
>> Used `Apache Maven 4.0.0-rc-3` and the simplest possible command `mvn
>> initialize` which demonstrates reproducible degradation, the build is using
>> 6 worker threads.
>> Maven 3 runs this command in 5 sec, Maven 4 - 6 minutes (no mistake).
>> YourKit highlighted as the most hot
>> `org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(RepositorySystemSession,
>> CollectRequest)` method.
>> I collected several stacktraces during the build and found this common part
>> of the stacktrace
>> ```
>> at
>> org.eclipse.aether.util.graph.manager.AbstractDependencyManager.deriveChildManager
>> at
>> org.eclipse.aether.internal.impl.collect.bf.BfDependencyCollector.doRecurse(BfDependencyCollector.java:361)
>> at
>> org.eclipse.aether.internal.impl.collect.bf.BfDependencyCollector.processDependency(BfDependencyCollector.java:320)
>> at
>> org.eclipse.aether.internal.impl.collect.bf.BfDependencyCollector.doCollectDependencies(BfDependencyCollector.java:202)
>> at
>> org.eclipse.aether.internal.impl.collect.DependencyCollectorDelegate.collectDependencies(DependencyCollectorDelegate.java:222)
>> at
>> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:79)
>> at
>> org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:241)
>> at
>> org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:157)
>> at
>> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:260)
>> at
>> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectArtifacts(LifecycleDependencyResolver.java:208)
>> - locked <xxxxxxxxxxxx> (a
>> org.apache.maven.project.artifact.DefaultProjectArtifactsCache$CacheKey)
>> at
>> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:128)
>> at
>> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:368)
>> at
>> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:307)
>> at
>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:214)
>> at
>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:179)
>> at
>> org.apache.maven.lifecycle.internal.MojoExecutor$1.run(MojoExecutor.java:168)
>> at
>> org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute(DefaultMojosExecutionStrategy.java:39)
>> at
>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:165)
>> at
>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:110)
>> at
>> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder.lambda$createBuildCallable$1(MultiThreadedBuilder.java:191)
>> at
>> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$$Lambda$1189/0x0000000800526240.call(Unknown
>> Source)
>> at java.util.concurrent.FutureTask.run(java.base@17.0.14
>> /FutureTask.java:264)
>> at java.util.concurrent.Executors$RunnableAdapter.call(java.base@17.0.14
>> /Executors.java:539)
>> at java.util.concurrent.FutureTask.run(java.base@17.0.14
>> /FutureTask.java:264)
>> at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@17.0.14
>> /ThreadPoolExecutor.java:1136)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@17.0.14
>> /ThreadPoolExecutor.java:635)
>> at java.lang.Thread.run(java.base@17.0.14/Thread.java:840)
>> ```
>> As you see, the top method in the snippet is `deriveChildManager` and in
>> the captured stack traces there are different combinations of stacktraces
>> above it. But the below part is always the same.
>> In this gist you can find 4 real stacktraces of the same Maven process
>> captured during the build when it was already slow
>> https://gist.github.com/seregamorph/bace2d5087ba195279583704bb41a5c4
>>
>> Things I'd like to focus attention is: it looks like it's degrading
>> smoothly, maybe the degradation depends on the depth of dependency tree,
>> maybe on the number of transitive dependencies (correlating values). But in
>> the very beginning (first 400 modules) it goes quite fast. It does not fail
>> with OOM, so probably the problem is around some nested iterations.
>>
>> Let me know what else I can do (including patching maven to have more
>> sensors) as I'm not sure how to provide a reproducible project model (it is
>> private).
>> I tried the gradle performance testing tool
>> https://gist.github.com/melix/c09f6d8d27b0005302cc3317c9c9be05 , but the
>> project that it generates does not reproduce the problem (probably because
>> the dependency tree of the huge multi-module project is almost flat).
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0 Release - Thoughts?
Posted by Michael Bien <mb...@gmail.com>.
Hi,
3/4 stack traces you posted contained the constructor frame with the Objects.hash() call.
Hash code over so many collections can scale badly once the collections grow:
https://github.com/apache/maven-resolver/blob/145588be6d5b2c0111b5f367787d4c9347c326da/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/manager/AbstractDependencyManager.java#L118-L126
It will grab every key/value pair and call hashCode() on it to build the final value.
If the dependency manager isn't put into Sets/Maps the hashcode could be potentially
calculated lazily (which would ideally not compute it at all and avoid the problem).
But I haven't looked at the code any deeper than that - maybe this isn't possible.
(as sidenote: managedLocalPaths is missing in equals)
I do like using async-profiler* in situations like this since it is easy to use and
the flame graphs often provide a good overview showing relative CPU usage. But in this
case you likely already found the bottleneck in the stacktraces you took.
usage would be:
sudo sysctl kernel.kptr_restrict=0 && sudo sysctl kernel.perf_event_paranoid=1
export MAVEN_OPTS=-agentpath:/path/to/async-profiler-4.0-linux-x64/lib/libasyncProfiler.so=start,event=cpu,file=maven.html
run mvn command. Check maven.html.
best regards,
michael
* https://github.com/async-profiler/async-profiler
On 6/10/25 18:10, Sergey Chernov wrote:
> I was able to run the Maven build (~900 modules) with the profiler.
> Used `Apache Maven 4.0.0-rc-3` and the simplest possible command `mvn
> initialize` which demonstrates reproducible degradation, the build is using
> 6 worker threads.
> Maven 3 runs this command in 5 sec, Maven 4 - 6 minutes (no mistake).
> YourKit highlighted as the most hot
> `org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(RepositorySystemSession,
> CollectRequest)` method.
> I collected several stacktraces during the build and found this common part
> of the stacktrace
> ```
> at
> org.eclipse.aether.util.graph.manager.AbstractDependencyManager.deriveChildManager
> at
> org.eclipse.aether.internal.impl.collect.bf.BfDependencyCollector.doRecurse(BfDependencyCollector.java:361)
> at
> org.eclipse.aether.internal.impl.collect.bf.BfDependencyCollector.processDependency(BfDependencyCollector.java:320)
> at
> org.eclipse.aether.internal.impl.collect.bf.BfDependencyCollector.doCollectDependencies(BfDependencyCollector.java:202)
> at
> org.eclipse.aether.internal.impl.collect.DependencyCollectorDelegate.collectDependencies(DependencyCollectorDelegate.java:222)
> at
> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:79)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:241)
> at
> org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:157)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:260)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectArtifacts(LifecycleDependencyResolver.java:208)
> - locked <xxxxxxxxxxxx> (a
> org.apache.maven.project.artifact.DefaultProjectArtifactsCache$CacheKey)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:128)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:368)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:307)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:214)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:179)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor$1.run(MojoExecutor.java:168)
> at
> org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute(DefaultMojosExecutionStrategy.java:39)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:165)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:110)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder.lambda$createBuildCallable$1(MultiThreadedBuilder.java:191)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$$Lambda$1189/0x0000000800526240.call(Unknown
> Source)
> at java.util.concurrent.FutureTask.run(java.base@17.0.14
> /FutureTask.java:264)
> at java.util.concurrent.Executors$RunnableAdapter.call(java.base@17.0.14
> /Executors.java:539)
> at java.util.concurrent.FutureTask.run(java.base@17.0.14
> /FutureTask.java:264)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@17.0.14
> /ThreadPoolExecutor.java:1136)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@17.0.14
> /ThreadPoolExecutor.java:635)
> at java.lang.Thread.run(java.base@17.0.14/Thread.java:840)
> ```
> As you see, the top method in the snippet is `deriveChildManager` and in
> the captured stack traces there are different combinations of stacktraces
> above it. But the below part is always the same.
> In this gist you can find 4 real stacktraces of the same Maven process
> captured during the build when it was already slow
> https://gist.github.com/seregamorph/bace2d5087ba195279583704bb41a5c4
>
> Things I'd like to focus attention is: it looks like it's degrading
> smoothly, maybe the degradation depends on the depth of dependency tree,
> maybe on the number of transitive dependencies (correlating values). But in
> the very beginning (first 400 modules) it goes quite fast. It does not fail
> with OOM, so probably the problem is around some nested iterations.
>
> Let me know what else I can do (including patching maven to have more
> sensors) as I'm not sure how to provide a reproducible project model (it is
> private).
> I tried the gradle performance testing tool
> https://gist.github.com/melix/c09f6d8d27b0005302cc3317c9c9be05 , but the
> project that it generates does not reproduce the problem (probably because
> the dependency tree of the huge multi-module project is almost flat).
>
>
> On Fri, May 30, 2025 at 1:59 PM Xeno Amess <xe...@gmail.com> wrote:
>
>> @Guillaume Nodet
>> [MNG-8510] Avoid duplicate Utils classes (#2173)
>>
>> https://github.com/JetBrains/intellij-community/blob/4054fd36584fb2bbb1ed983d7d36cefca040c2cf/plugins/maven/maven40-server-impl/src/com/intellij/maven/server/m40/Maven40ServerEmbedderImpl.java#L74
>>
>> yes we can release the version 4.0.0, but after the releasing things like
>> this class/file-names would not be changed easily (of course and other
>> bigger things), I don't know if people be prepared for a...stablization
>>
>> Xeno Amess <xe...@gmail.com> 于2025年5月29日周四 17:21写道：
>>
>>> all running with skipTests
>>>
>>> log4j both success, mvn3 2:00 mvn4 1:50
>>> dubbo both success, mvn3 3:08 mvn4 3:19
>>>
>>> hadoop failed due to network reason(for yarn frontend, well considering
>>> about where I'm living it is normal...)
>>>
>>> for structs 2, 90%+ time is wasted on antrun for docs generation in
>>> struts2-assembly. both mvn3 and mvn4 be very very slow there.
>>>
>>>
>>> jetty seems has profile-plugin leak when using mvn4.
>>> maven-assembly-plugin:3.7.1 wrongly invoking a bom sub-project, which is
>>> only defined in a profile (named `config`) which shall not be on.
>>>
>>> quarkus cannot build with mvn4, maven-invoker-plugin failed
>>>
>>> Xeno Amess <xe...@gmail.com> 于2025年5月29日周四 14:52写道：
>>>
>>>> nope. neither can the github master latest.
>>>>
>>>> Xeno Amess <xe...@gmail.com> 于2025年5月29日周四 14:40写道：
>>>>
>>>>> I used apache-maven-4.0.0-rc-3 btw. I would have a try at the latest
>>>>> github code version...
>>>>>
>>>>> Xeno Amess <xe...@gmail.com> 于2025年5月29日周四 14:39写道：
>>>>>
>>>>>> jetty is a good example.
>>>>>> mvn3 can build but mvn4 cannot.
>>>>>>
>>>>>> maven-assembly-plugin:3.7.1 wrongly invoking a bom sub-project
>>>>>>
>>>>>> [INFO] ---------------< org.eclipse.jetty.ee10:jetty-ee10-bom
>>>>>>> ----------------
>>>>>> [INFO] Building EE10 :: BOM 12.0.22-SNAPSHOT
>>>>>> [90/354]
>>>>>> [INFO] from jetty-ee10/jetty-ee10-bom/pom.xml
>>>>>> [INFO] --------------------------------[ pom
>>>>>> ]---------------------------------
>>>>>> [INFO] Going to calculate checksum for project
>>>>>> [groupId=org.eclipse.jetty.ee10, artifactId=jetty-ee10-bom,
>>>>>> version=12.0.22-SNAPSHOT]
>>>>>> [INFO] Project inputs calculated in 0 ms. XXMM checksum
>>>>>> [7b7b6120251dfd1d] calculated in 0 ms.
>>>>>> [INFO] Attempting to restore project
>>>>>> org.eclipse.jetty.ee10:jetty-ee10-bom from build cache
>>>>>> [INFO] Local build found by checksum 7b7b6120251dfd1d
>>>>>> [INFO] Found cached build, restoring
>>>>>> org.eclipse.jetty.ee10:jetty-ee10-bom from cache by checksum
>>>>>> 7b7b6120251dfd1d
>>>>>> [WARNING] Cached build doesn't contains all requested plugin
>> executions
>>>>>> (missing:
>>>>>> [org.apache.maven.plugins:maven-resources-plugin:3.3.1:copy-resources
>>>>>> {execution: copy-resources},
>>>>>> org.apache.maven.plugins:maven-assembly-plugin:3.7.1:single
>> {execution:
>>>>>> config-assembly}]), cannot restore
>>>>>> [INFO] Local build was not found by checksum 7b7b6120251dfd1d for
>>>>>> org.eclipse.jetty.ee10:jetty-ee10-bom
>>>>>> [INFO]
>>>>>> [INFO] --- spotless:2.44.4:check (default) @ jetty-ee10-bom ---
>>>>>> [INFO] Index file does not exist. Fallback to an empty index
>>>>>> [INFO] Sorting file /tmp/pom11239457262347372795.xml
>>>>>> [INFO] Pom file is already sorted, exiting
>>>>>> [INFO] Spotless.Pom is keeping 1 files clean - 0 needs changes to be
>>>>>> clean, 1 were already clean, 0 were skipped because caching
>> determined they
>>>>>> were already clean
>>>>>> [INFO]
>>>>>> [INFO] --- checkstyle:3.6.0:check (checkstyle-check) @ jetty-ee10-bom
>>>>>> ---
>>>>>> [INFO] 开始检查……
>>>>>> 检查完成。
>>>>>> [INFO] You have 0 Checkstyle violations.
>>>>>> [INFO]
>>>>>> [INFO] --- enforcer:3.5.0:enforce (ban-javax-servlet-api) @
>>>>>> jetty-ee10-bom ---
>>>>>> [INFO] Rule 0:
>>>>>> org.apache.maven.enforcer.rules.dependency.BannedDependencies passed
>>>>>> [INFO]
>>>>>> [INFO] --- enforcer:3.5.0:enforce (enforce-java) @ jetty-ee10-bom ---
>>>>>> [INFO] Rule 3:
>>>>>>
>> org.eclipse.jetty.toolchain.enforcer.rules.RequireOsgiCompatibleVersionRule(versionOsgiRule)
>>>>>> passed
>>>>>> [INFO] Rule 4:
>>>>>> org.apache.maven.enforcer.rules.dependency.RequireUpperBoundDeps
>> passed
>>>>>> [INFO]
>>>>>> [INFO] --- build-helper:3.6.0:parse-version (set-osgi-version) @
>>>>>> jetty-ee10-bom ---
>>>>>> [INFO]
>>>>>> [INFO] --- jacoco:0.8.13:prepare-agent (jacoco-initialize) @
>>>>>> jetty-ee10-bom ---
>>>>>> [INFO] argLine set to
>>>>>>
>> -javaagent:/home/xenoamess/.m2/repository/org/jacoco/org.jacoco.agent/0.8.13/org.jacoco.agent-0.8.13-runtime.jar=destfile=/home/xenoamess/workspace/jetty.project/jetty-ee10/jetty-ee10-bom/target/jacoco.exec,excludes=**/org/eclipse/jetty/ant/**:*/org/eclipse/jetty/maven/its/**:**/org/eclipse/jetty/embedded/**:**/org/eclipse/jetty/asyncrest/**:**/org/eclipse/jetty/demo/**:**/org/eclipse/jetty/gcloud/**:**/org/eclipse/jetty/infinispan/**:**/org/eclipse/jetty/osgi/**:**/org/eclipse/jetty/spring/**:**/org/eclipse/jetty/http/spi/**:**/org/eclipse/jetty/tests/**:**/org/eclipse/jetty/test/**
>>>>>> [INFO]
>>>>>> [INFO] --- jacoco:0.8.13:prepare-agent (jacoco-setup-m-invoker-p) @
>>>>>> jetty-ee10-bom ---
>>>>>> [INFO] invoker.mavenOpts set to
>>>>>>
>> -javaagent:/home/xenoamess/.m2/repository/org/jacoco/org.jacoco.agent/0.8.13/org.jacoco.agent-0.8.13-runtime.jar=destfile=/home/xenoamess/workspace/jetty.project/jetty-ee10/jetty-ee10-bom/target/jacoco.exec,excludes=**/org/eclipse/jetty/ant/**:*/org/eclipse/jetty/maven/its/**:**/org/eclipse/jetty/embedded/**:**/org/eclipse/jetty/asyncrest/**:**/org/eclipse/jetty/demo/**:**/org/eclipse/jetty/gcloud/**:**/org/eclipse/jetty/infinispan/**:**/org/eclipse/jetty/osgi/**:**/org/eclipse/jetty/spring/**:**/org/eclipse/jetty/http/spi/**:**/org/eclipse/jetty/tests/**:**/org/eclipse/jetty/test/**
>>>>>> [INFO]
>>>>>> [INFO] --- remote-resources:3.2.0:process (copy-shared-resources) @
>>>>>> jetty-ee10-bom ---
>>>>>> [INFO] Preparing remote bundle
>>>>>> org.eclipse.jetty:build-resources:12.0.22-SNAPSHOT
>>>>>> [INFO] Copying 0 resource from 1 bundle.
>>>>>> [INFO]
>>>>>> [INFO] --- jetty-version:2.7:attach-version-text (attach-version) @
>>>>>> jetty-ee10-bom ---
>>>>>> [INFO]
>>>>>> [INFO] --- resources:3.3.1:copy-resources (copy-resources) @
>>>>>> jetty-ee10-bom ---
>>>>>> [INFO] skip non existing resourceDirectory
>>>>>>
>> /home/xenoamess/workspace/jetty.project/jetty-ee10/jetty-ee10-bom/src/main/config
>>>>>> [INFO]
>>>>>> [INFO] --- flatten:1.7.0:flatten (flatten) @ jetty-ee10-bom ---
>>>>>> [INFO] Generating flattened POM of project
>>>>>> org.eclipse.jetty.ee10:jetty-ee10-bom:pom:12.0.22-SNAPSHOT...
>>>>>> [INFO]
>>>>>> [INFO] --- bundle:5.1.9:manifest (default) @ jetty-ee10-bom ---
>>>>>> [WARNING] Ignoring project type pom - supportedProjectTypes = [jar,
>>>>>> maven-plugin]
>>>>>> [INFO]
>>>>>> [INFO] --- source:3.3.1:jar-no-fork (attach-sources) @ jetty-ee10-bom
>>>>>> ---
>>>>>> [INFO]
>>>>>> [INFO] --- jacoco:0.8.13:report (jacoco-site) @ jetty-ee10-bom ---
>>>>>> [INFO] Skipping JaCoCo execution due to missing execution data file.
>>>>>> [INFO]
>>>>>> [INFO] --- assembly:3.7.1:single (config-assembly) @ jetty-ee10-bom
>> ---
>>>>>>
>>>>>>
>>>>>> [INFO] Mimir session closed (RETRIEVED=0 CACHED=0)
>>>>>> [ERROR] Failed to execute goal
>>>>>> org.apache.maven.plugins:maven-assembly-plugin:3.7.1:single
>>>>>> (config-assembly) on project jetty-ee10-bom: Failed to create
>> assembly:
>>>>>> Error creating assembly archive config: archive cannot be empty ->
>> [Help 1]
>>>>>> [ERROR]
>>>>>>
>>>>>>
>>>>>> checked it did not invoke in mvn3 building log...
>>>>>>
>>>>>> Sergey Chernov <se...@gmail.com> 于2025年5月29日周四 00:17写道：
>>>>>>
>>>>>>> Hey, Delany. I will look into this.
>>>>>>> Also to avoid confusion let's continue this discussion in the proper
>>>>>>> thread
>>>>>>> as it's not related to maven 4 release
>>>>>>>
>>>>>>> On Wed, May 28, 2025 at 4:22 PM Delany <de...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Sergei,
>>>>>>>>
>>>>>>>> I'm running with this extension going forward. I don't use the
>> build
>>>>>>> cache
>>>>>>>> (yet) so that's not an issue.
>>>>>>>> When trying to promote unit tests to a company that's resistant its
>>>>>>> helpful
>>>>>>>> to be able to say the tests won't slow down the build.
>>>>>>>>
>>>>>>>> We have one huge module though (project we're calling it now) with
>>>>>>>> extensive tests, and its a bottleneck for all that follow.
>>>>>>>> Typically we had to skip tests, but now we don't have to. Build
>> time
>>>>>>> was
>>>>>>>> cut in half.
>>>>>>>>
>>>>>>>> I did notice jacoco coverage was disabled as I bound the
>>>>>>>> jacoco-maven-plugin report goal to the prepare-package phase.
>>>>>>>> As the documentation says, the phases have been switched around.
>>>>>>>> But can you make it work with the
>> buildplan-maven-plugin:list-phases
>>>>>>> goal
>>>>>>>> so I can actually see which phases runs when, or is that up to this
>>>>>>> plugin
>>>>>>>> to figure out?
>>>>>>>>
>>>>>>>> Kind regards,
>>>>>>>> Delany
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, 28 May 2025 at 14:55, Sergey Chernov <
>> serega.morph@gmail.com
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Guillaume, that's awesome. It's good that there is no rush with
>> it.
>>>>>>>>> Once I'll have insights, I'll share them.
>>>>>>>>>
>>>>>>>>> Xeno, the project I'm checking is private unfortunately. Also
>> this
>>>>>>> can be
>>>>>>>>> quite challenging to find a good Maven multi-module project as a
>>>>>>>> reference
>>>>>>>>> for performance testing and compatibility validations, as many of
>>>>>>> big
>>>>>>>>> projects e.g. have flaky tests and other issues.
>>>>>>>>> Some of the biggest that I've seen:
>>>>>>>>> * https://github.com/quarkusio/quarkus (has lots of
>>>>>>> customizations in
>>>>>>>>> .mvn/extensions.xml)
>>>>>>>>> * https://github.com/apache/dubbo
>>>>>>>>> * https://github.com/apache/hadoop
>>>>>>>>> * https://github.com/apache/struts
>>>>>>>>> * https://github.com/vaadin/flow and
>>>>>>> https://github.com/vaadin/framework
>>>>>>>>>
>>>>>>>>> On Wed, May 28, 2025 at 2:16 PM Guillaume Nodet <
>> gnodet@apache.org
>>>>>>>> wrote:
>>>>>>>>>> After considering the concerns about API stability, plugin
>>>>>>>>>> compatibility, and the performance issues reported by Sergey
>> (4x
>>>>>>>>>> slower in rc3), I agree with Sylwester, Benjamin, and Elliotte
>>>>>>> that we
>>>>>>>>>> should opt for an rc4 to address these issues. My proposal is
>> to
>>>>>>>>>> release a final release candidate (rc4) soon, aiming for a
>>>>>>> General
>>>>>>>>>> Availability (GA) release in September. Post rc4, I suggest
>>>>>>> creating a
>>>>>>>>>> 4.0.x branch to start work on 4.1.0. For 4.1.0, we could
>>>>>>> introduce API
>>>>>>>>>> changes like records and sequenced collections, as well as new
>>>>>>>>>> features such as mixins, cascading profiles, server aliases,
>> JDK
>>>>>>> 21
>>>>>>>>>> (still under discussion) and more....
>>>>>>>>>>
>>>>>>>>>> The recent API changes for JPMS, as Martin noted, only affect
>> the
>>>>>>>>>> experimental API, so they shouldn’t block the release. On
>>>>>>> Matthias’s
>>>>>>>>>> suggestion, enabling GitHub Issues across all repositories
>>>>>>> before the
>>>>>>>>>> GA seems like a good idea to improve user feedback. Let’s focus
>>>>>>> on
>>>>>>>>>> stabilizing rc4 and addressing performance bottlenecks,
>> possibly
>>>>>>>>>> exploring Martin’s O(N²) concerns with profiling, as Sergey
>>>>>>> offered.
>>>>>>>>>> What do you think about this plan?
>>>>>>>>>>
>>>>>>>>>> On a side note, I created a few months ago a project to check
>>>>>>> Maven 4
>>>>>>>>>> compatibility with all Apache projects using Maven. The
>> results
>>>>>>> for
>>>>>>>>>> RC-3 can be found at
>>>>>>>>>> https://github.com/gnodet/maven4-testing/issues/2812. Most of
>>>>>>> the
>>>>>>>>>> errors are caused by the use of incompatible plugins (which
>>>>>>> needs to
>>>>>>>>>> be updated) or incorrect POMs (as Maven 4 is more strict about
>> a
>>>>>>> few
>>>>>>>>>> things). What would be nice is a tool to integrate in the
>> shell
>>>>>>> that
>>>>>>>>>> would fix those known incompatibilities, so that users would
>>>>>>> have an
>>>>>>>>>> easier migration path. And we could apply it to this project
>> to
>>>>>>> make
>>>>>>>>>> more green boxes.
>>>>>>>>>>
>>>>>>>>>> Le mer. 21 mai 2025 à 08:11, Guillaume Nodet <
>> gnodet@apache.org>
>>>>>>> a
>>>>>>>>> écrit :
>>>>>>>>>>> Hey Maven Devs,
>>>>>>>>>>>
>>>>>>>>>>> We're gearing up to release a new version from the master
>>>>>>> branch. I'm
>>>>>>>>>> thinking we should go for 4.0.0 instead of rc-4. What do you
>> all
>>>>>>> think?
>>>>>>>>> Any
>>>>>>>>>> feedback or ideas on the versioning or release plan? Let’s hear
>>>>>>> it!
>>>>>>>>>>> Cheers,
>>>>>>>>>>>
>>>>>>>>>>> Guillaume
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> ------------------------
>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0 Release - Thoughts?
Posted by Sergey Chernov <se...@gmail.com>.
I was able to run the Maven build (~900 modules) with the profiler.
Used `Apache Maven 4.0.0-rc-3` and the simplest possible command `mvn
initialize` which demonstrates reproducible degradation, the build is using
6 worker threads.
Maven 3 runs this command in 5 sec, Maven 4 - 6 minutes (no mistake).
YourKit highlighted as the most hot
`org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(RepositorySystemSession,
CollectRequest)` method.
I collected several stacktraces during the build and found this common part
of the stacktrace
```
at
org.eclipse.aether.util.graph.manager.AbstractDependencyManager.deriveChildManager
at
org.eclipse.aether.internal.impl.collect.bf.BfDependencyCollector.doRecurse(BfDependencyCollector.java:361)
at
org.eclipse.aether.internal.impl.collect.bf.BfDependencyCollector.processDependency(BfDependencyCollector.java:320)
at
org.eclipse.aether.internal.impl.collect.bf.BfDependencyCollector.doCollectDependencies(BfDependencyCollector.java:202)
at
org.eclipse.aether.internal.impl.collect.DependencyCollectorDelegate.collectDependencies(DependencyCollectorDelegate.java:222)
at
org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:79)
at
org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:241)
at
org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:157)
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:260)
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectArtifacts(LifecycleDependencyResolver.java:208)
- locked <xxxxxxxxxxxx> (a
org.apache.maven.project.artifact.DefaultProjectArtifactsCache$CacheKey)
at
org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:128)
at
org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:368)
at
org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:307)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:214)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:179)
at
org.apache.maven.lifecycle.internal.MojoExecutor$1.run(MojoExecutor.java:168)
at
org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute(DefaultMojosExecutionStrategy.java:39)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:165)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:110)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder.lambda$createBuildCallable$1(MultiThreadedBuilder.java:191)
at
org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$$Lambda$1189/0x0000000800526240.call(Unknown
Source)
at java.util.concurrent.FutureTask.run(java.base@17.0.14
/FutureTask.java:264)
at java.util.concurrent.Executors$RunnableAdapter.call(java.base@17.0.14
/Executors.java:539)
at java.util.concurrent.FutureTask.run(java.base@17.0.14
/FutureTask.java:264)
at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@17.0.14
/ThreadPoolExecutor.java:1136)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@17.0.14
/ThreadPoolExecutor.java:635)
at java.lang.Thread.run(java.base@17.0.14/Thread.java:840)
```
As you see, the top method in the snippet is `deriveChildManager` and in
the captured stack traces there are different combinations of stacktraces
above it. But the below part is always the same.
In this gist you can find 4 real stacktraces of the same Maven process
captured during the build when it was already slow
https://gist.github.com/seregamorph/bace2d5087ba195279583704bb41a5c4
Things I'd like to focus attention is: it looks like it's degrading
smoothly, maybe the degradation depends on the depth of dependency tree,
maybe on the number of transitive dependencies (correlating values). But in
the very beginning (first 400 modules) it goes quite fast. It does not fail
with OOM, so probably the problem is around some nested iterations.
Let me know what else I can do (including patching maven to have more
sensors) as I'm not sure how to provide a reproducible project model (it is
private).
I tried the gradle performance testing tool
https://gist.github.com/melix/c09f6d8d27b0005302cc3317c9c9be05 , but the
project that it generates does not reproduce the problem (probably because
the dependency tree of the huge multi-module project is almost flat).
On Fri, May 30, 2025 at 1:59 PM Xeno Amess <xe...@gmail.com> wrote:
> @Guillaume Nodet
> [MNG-8510] Avoid duplicate Utils classes (#2173)
>
> https://github.com/JetBrains/intellij-community/blob/4054fd36584fb2bbb1ed983d7d36cefca040c2cf/plugins/maven/maven40-server-impl/src/com/intellij/maven/server/m40/Maven40ServerEmbedderImpl.java#L74
>
> yes we can release the version 4.0.0, but after the releasing things like
> this class/file-names would not be changed easily (of course and other
> bigger things), I don't know if people be prepared for a...stablization
>
> Xeno Amess <xe...@gmail.com> 于2025年5月29日周四 17:21写道：
>
> > all running with skipTests
> >
> > log4j both success, mvn3 2:00 mvn4 1:50
> > dubbo both success, mvn3 3:08 mvn4 3:19
> >
> > hadoop failed due to network reason(for yarn frontend, well considering
> > about where I'm living it is normal...)
> >
> > for structs 2, 90%+ time is wasted on antrun for docs generation in
> > struts2-assembly. both mvn3 and mvn4 be very very slow there.
> >
> >
> > jetty seems has profile-plugin leak when using mvn4.
> > maven-assembly-plugin:3.7.1 wrongly invoking a bom sub-project, which is
> > only defined in a profile (named `config`) which shall not be on.
> >
> > quarkus cannot build with mvn4, maven-invoker-plugin failed
> >
> > Xeno Amess <xe...@gmail.com> 于2025年5月29日周四 14:52写道：
> >
> >> nope. neither can the github master latest.
> >>
> >> Xeno Amess <xe...@gmail.com> 于2025年5月29日周四 14:40写道：
> >>
> >>> I used apache-maven-4.0.0-rc-3 btw. I would have a try at the latest
> >>> github code version...
> >>>
> >>> Xeno Amess <xe...@gmail.com> 于2025年5月29日周四 14:39写道：
> >>>
> >>>> jetty is a good example.
> >>>> mvn3 can build but mvn4 cannot.
> >>>>
> >>>> maven-assembly-plugin:3.7.1 wrongly invoking a bom sub-project
> >>>>
> >>>> [INFO] ---------------< org.eclipse.jetty.ee10:jetty-ee10-bom
> >>>> >----------------
> >>>> [INFO] Building EE10 :: BOM 12.0.22-SNAPSHOT
> >>>> [90/354]
> >>>> [INFO] from jetty-ee10/jetty-ee10-bom/pom.xml
> >>>> [INFO] --------------------------------[ pom
> >>>> ]---------------------------------
> >>>> [INFO] Going to calculate checksum for project
> >>>> [groupId=org.eclipse.jetty.ee10, artifactId=jetty-ee10-bom,
> >>>> version=12.0.22-SNAPSHOT]
> >>>> [INFO] Project inputs calculated in 0 ms. XXMM checksum
> >>>> [7b7b6120251dfd1d] calculated in 0 ms.
> >>>> [INFO] Attempting to restore project
> >>>> org.eclipse.jetty.ee10:jetty-ee10-bom from build cache
> >>>> [INFO] Local build found by checksum 7b7b6120251dfd1d
> >>>> [INFO] Found cached build, restoring
> >>>> org.eclipse.jetty.ee10:jetty-ee10-bom from cache by checksum
> >>>> 7b7b6120251dfd1d
> >>>> [WARNING] Cached build doesn't contains all requested plugin
> executions
> >>>> (missing:
> >>>> [org.apache.maven.plugins:maven-resources-plugin:3.3.1:copy-resources
> >>>> {execution: copy-resources},
> >>>> org.apache.maven.plugins:maven-assembly-plugin:3.7.1:single
> {execution:
> >>>> config-assembly}]), cannot restore
> >>>> [INFO] Local build was not found by checksum 7b7b6120251dfd1d for
> >>>> org.eclipse.jetty.ee10:jetty-ee10-bom
> >>>> [INFO]
> >>>> [INFO] --- spotless:2.44.4:check (default) @ jetty-ee10-bom ---
> >>>> [INFO] Index file does not exist. Fallback to an empty index
> >>>> [INFO] Sorting file /tmp/pom11239457262347372795.xml
> >>>> [INFO] Pom file is already sorted, exiting
> >>>> [INFO] Spotless.Pom is keeping 1 files clean - 0 needs changes to be
> >>>> clean, 1 were already clean, 0 were skipped because caching
> determined they
> >>>> were already clean
> >>>> [INFO]
> >>>> [INFO] --- checkstyle:3.6.0:check (checkstyle-check) @ jetty-ee10-bom
> >>>> ---
> >>>> [INFO] 开始检查……
> >>>> 检查完成。
> >>>> [INFO] You have 0 Checkstyle violations.
> >>>> [INFO]
> >>>> [INFO] --- enforcer:3.5.0:enforce (ban-javax-servlet-api) @
> >>>> jetty-ee10-bom ---
> >>>> [INFO] Rule 0:
> >>>> org.apache.maven.enforcer.rules.dependency.BannedDependencies passed
> >>>> [INFO]
> >>>> [INFO] --- enforcer:3.5.0:enforce (enforce-java) @ jetty-ee10-bom ---
> >>>> [INFO] Rule 3:
> >>>>
> org.eclipse.jetty.toolchain.enforcer.rules.RequireOsgiCompatibleVersionRule(versionOsgiRule)
> >>>> passed
> >>>> [INFO] Rule 4:
> >>>> org.apache.maven.enforcer.rules.dependency.RequireUpperBoundDeps
> passed
> >>>> [INFO]
> >>>> [INFO] --- build-helper:3.6.0:parse-version (set-osgi-version) @
> >>>> jetty-ee10-bom ---
> >>>> [INFO]
> >>>> [INFO] --- jacoco:0.8.13:prepare-agent (jacoco-initialize) @
> >>>> jetty-ee10-bom ---
> >>>> [INFO] argLine set to
> >>>>
> -javaagent:/home/xenoamess/.m2/repository/org/jacoco/org.jacoco.agent/0.8.13/org.jacoco.agent-0.8.13-runtime.jar=destfile=/home/xenoamess/workspace/jetty.project/jetty-ee10/jetty-ee10-bom/target/jacoco.exec,excludes=**/org/eclipse/jetty/ant/**:*/org/eclipse/jetty/maven/its/**:**/org/eclipse/jetty/embedded/**:**/org/eclipse/jetty/asyncrest/**:**/org/eclipse/jetty/demo/**:**/org/eclipse/jetty/gcloud/**:**/org/eclipse/jetty/infinispan/**:**/org/eclipse/jetty/osgi/**:**/org/eclipse/jetty/spring/**:**/org/eclipse/jetty/http/spi/**:**/org/eclipse/jetty/tests/**:**/org/eclipse/jetty/test/**
> >>>> [INFO]
> >>>> [INFO] --- jacoco:0.8.13:prepare-agent (jacoco-setup-m-invoker-p) @
> >>>> jetty-ee10-bom ---
> >>>> [INFO] invoker.mavenOpts set to
> >>>>
> -javaagent:/home/xenoamess/.m2/repository/org/jacoco/org.jacoco.agent/0.8.13/org.jacoco.agent-0.8.13-runtime.jar=destfile=/home/xenoamess/workspace/jetty.project/jetty-ee10/jetty-ee10-bom/target/jacoco.exec,excludes=**/org/eclipse/jetty/ant/**:*/org/eclipse/jetty/maven/its/**:**/org/eclipse/jetty/embedded/**:**/org/eclipse/jetty/asyncrest/**:**/org/eclipse/jetty/demo/**:**/org/eclipse/jetty/gcloud/**:**/org/eclipse/jetty/infinispan/**:**/org/eclipse/jetty/osgi/**:**/org/eclipse/jetty/spring/**:**/org/eclipse/jetty/http/spi/**:**/org/eclipse/jetty/tests/**:**/org/eclipse/jetty/test/**
> >>>> [INFO]
> >>>> [INFO] --- remote-resources:3.2.0:process (copy-shared-resources) @
> >>>> jetty-ee10-bom ---
> >>>> [INFO] Preparing remote bundle
> >>>> org.eclipse.jetty:build-resources:12.0.22-SNAPSHOT
> >>>> [INFO] Copying 0 resource from 1 bundle.
> >>>> [INFO]
> >>>> [INFO] --- jetty-version:2.7:attach-version-text (attach-version) @
> >>>> jetty-ee10-bom ---
> >>>> [INFO]
> >>>> [INFO] --- resources:3.3.1:copy-resources (copy-resources) @
> >>>> jetty-ee10-bom ---
> >>>> [INFO] skip non existing resourceDirectory
> >>>>
> /home/xenoamess/workspace/jetty.project/jetty-ee10/jetty-ee10-bom/src/main/config
> >>>> [INFO]
> >>>> [INFO] --- flatten:1.7.0:flatten (flatten) @ jetty-ee10-bom ---
> >>>> [INFO] Generating flattened POM of project
> >>>> org.eclipse.jetty.ee10:jetty-ee10-bom:pom:12.0.22-SNAPSHOT...
> >>>> [INFO]
> >>>> [INFO] --- bundle:5.1.9:manifest (default) @ jetty-ee10-bom ---
> >>>> [WARNING] Ignoring project type pom - supportedProjectTypes = [jar,
> >>>> maven-plugin]
> >>>> [INFO]
> >>>> [INFO] --- source:3.3.1:jar-no-fork (attach-sources) @ jetty-ee10-bom
> >>>> ---
> >>>> [INFO]
> >>>> [INFO] --- jacoco:0.8.13:report (jacoco-site) @ jetty-ee10-bom ---
> >>>> [INFO] Skipping JaCoCo execution due to missing execution data file.
> >>>> [INFO]
> >>>> [INFO] --- assembly:3.7.1:single (config-assembly) @ jetty-ee10-bom
> ---
> >>>>
> >>>>
> >>>>
> >>>> [INFO] Mimir session closed (RETRIEVED=0 CACHED=0)
> >>>> [ERROR] Failed to execute goal
> >>>> org.apache.maven.plugins:maven-assembly-plugin:3.7.1:single
> >>>> (config-assembly) on project jetty-ee10-bom: Failed to create
> assembly:
> >>>> Error creating assembly archive config: archive cannot be empty ->
> [Help 1]
> >>>> [ERROR]
> >>>>
> >>>>
> >>>> checked it did not invoke in mvn3 building log...
> >>>>
> >>>> Sergey Chernov <se...@gmail.com> 于2025年5月29日周四 00:17写道：
> >>>>
> >>>>> Hey, Delany. I will look into this.
> >>>>> Also to avoid confusion let's continue this discussion in the proper
> >>>>> thread
> >>>>> as it's not related to maven 4 release
> >>>>>
> >>>>> On Wed, May 28, 2025 at 4:22 PM Delany <de...@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>> > Hi Sergei,
> >>>>> >
> >>>>> > I'm running with this extension going forward. I don't use the
> build
> >>>>> cache
> >>>>> > (yet) so that's not an issue.
> >>>>> > When trying to promote unit tests to a company that's resistant its
> >>>>> helpful
> >>>>> > to be able to say the tests won't slow down the build.
> >>>>> >
> >>>>> > We have one huge module though (project we're calling it now) with
> >>>>> > extensive tests, and its a bottleneck for all that follow.
> >>>>> > Typically we had to skip tests, but now we don't have to. Build
> time
> >>>>> was
> >>>>> > cut in half.
> >>>>> >
> >>>>> > I did notice jacoco coverage was disabled as I bound the
> >>>>> > jacoco-maven-plugin report goal to the prepare-package phase.
> >>>>> > As the documentation says, the phases have been switched around.
> >>>>> > But can you make it work with the
> buildplan-maven-plugin:list-phases
> >>>>> goal
> >>>>> > so I can actually see which phases runs when, or is that up to this
> >>>>> plugin
> >>>>> > to figure out?
> >>>>> >
> >>>>> > Kind regards,
> >>>>> > Delany
> >>>>> >
> >>>>> >
> >>>>> > On Wed, 28 May 2025 at 14:55, Sergey Chernov <
> serega.morph@gmail.com
> >>>>> >
> >>>>> > wrote:
> >>>>> >
> >>>>> > > Guillaume, that's awesome. It's good that there is no rush with
> it.
> >>>>> > > Once I'll have insights, I'll share them.
> >>>>> > >
> >>>>> > > Xeno, the project I'm checking is private unfortunately. Also
> this
> >>>>> can be
> >>>>> > > quite challenging to find a good Maven multi-module project as a
> >>>>> > reference
> >>>>> > > for performance testing and compatibility validations, as many of
> >>>>> big
> >>>>> > > projects e.g. have flaky tests and other issues.
> >>>>> > > Some of the biggest that I've seen:
> >>>>> > > * https://github.com/quarkusio/quarkus (has lots of
> >>>>> customizations in
> >>>>> > > .mvn/extensions.xml)
> >>>>> > > * https://github.com/apache/dubbo
> >>>>> > > * https://github.com/apache/hadoop
> >>>>> > > * https://github.com/apache/struts
> >>>>> > > * https://github.com/vaadin/flow and
> >>>>> https://github.com/vaadin/framework
> >>>>> > >
> >>>>> > >
> >>>>> > > On Wed, May 28, 2025 at 2:16 PM Guillaume Nodet <
> gnodet@apache.org
> >>>>> >
> >>>>> > wrote:
> >>>>> > >
> >>>>> > > > After considering the concerns about API stability, plugin
> >>>>> > > > compatibility, and the performance issues reported by Sergey
> (4x
> >>>>> > > > slower in rc3), I agree with Sylwester, Benjamin, and Elliotte
> >>>>> that we
> >>>>> > > > should opt for an rc4 to address these issues. My proposal is
> to
> >>>>> > > > release a final release candidate (rc4) soon, aiming for a
> >>>>> General
> >>>>> > > > Availability (GA) release in September. Post rc4, I suggest
> >>>>> creating a
> >>>>> > > > 4.0.x branch to start work on 4.1.0. For 4.1.0, we could
> >>>>> introduce API
> >>>>> > > > changes like records and sequenced collections, as well as new
> >>>>> > > > features such as mixins, cascading profiles, server aliases,
> JDK
> >>>>> 21
> >>>>> > > > (still under discussion) and more....
> >>>>> > > >
> >>>>> > > > The recent API changes for JPMS, as Martin noted, only affect
> the
> >>>>> > > > experimental API, so they shouldn’t block the release. On
> >>>>> Matthias’s
> >>>>> > > > suggestion, enabling GitHub Issues across all repositories
> >>>>> before the
> >>>>> > > > GA seems like a good idea to improve user feedback. Let’s focus
> >>>>> on
> >>>>> > > > stabilizing rc4 and addressing performance bottlenecks,
> possibly
> >>>>> > > > exploring Martin’s O(N²) concerns with profiling, as Sergey
> >>>>> offered.
> >>>>> > > >
> >>>>> > > > What do you think about this plan?
> >>>>> > > >
> >>>>> > > > On a side note, I created a few months ago a project to check
> >>>>> Maven 4
> >>>>> > > > compatibility with all Apache projects using Maven. The
> results
> >>>>> for
> >>>>> > > > RC-3 can be found at
> >>>>> > > > https://github.com/gnodet/maven4-testing/issues/2812. Most of
> >>>>> the
> >>>>> > > > errors are caused by the use of incompatible plugins (which
> >>>>> needs to
> >>>>> > > > be updated) or incorrect POMs (as Maven 4 is more strict about
> a
> >>>>> few
> >>>>> > > > things). What would be nice is a tool to integrate in the
> shell
> >>>>> that
> >>>>> > > > would fix those known incompatibilities, so that users would
> >>>>> have an
> >>>>> > > > easier migration path. And we could apply it to this project
> to
> >>>>> make
> >>>>> > > > more green boxes.
> >>>>> > > >
> >>>>> > > > Le mer. 21 mai 2025 à 08:11, Guillaume Nodet <
> gnodet@apache.org>
> >>>>> a
> >>>>> > > écrit :
> >>>>> > > > >
> >>>>> > > > > Hey Maven Devs,
> >>>>> > > > >
> >>>>> > > > > We're gearing up to release a new version from the master
> >>>>> branch. I'm
> >>>>> > > > thinking we should go for 4.0.0 instead of rc-4. What do you
> all
> >>>>> think?
> >>>>> > > Any
> >>>>> > > > feedback or ideas on the versioning or release plan? Let’s hear
> >>>>> it!
> >>>>> > > > >
> >>>>> > > > > Cheers,
> >>>>> > > > >
> >>>>> > > > > Guillaume
> >>>>> > > > >
> >>>>> > > > >
> >>>>> > > >
> >>>>> > > >
> >>>>> > > > --
> >>>>> > > > ------------------------
> >>>>> > > > Guillaume Nodet
> >>>>> > > >
> >>>>> > > >
> >>>>> ---------------------------------------------------------------------
> >>>>> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>> > > > For additional commands, e-mail: dev-help@maven.apache.org
> >>>>> > > >
> >>>>> > > >
> >>>>> > >
> >>>>> >
> >>>>>
> >>>>
>
Re: Maven 4.0.0 Release - Thoughts?
Posted by Xeno Amess <xe...@gmail.com>.
@Guillaume Nodet
[MNG-8510] Avoid duplicate Utils classes (#2173)
https://github.com/JetBrains/intellij-community/blob/4054fd36584fb2bbb1ed983d7d36cefca040c2cf/plugins/maven/maven40-server-impl/src/com/intellij/maven/server/m40/Maven40ServerEmbedderImpl.java#L74
yes we can release the version 4.0.0, but after the releasing things like
this class/file-names would not be changed easily (of course and other
bigger things), I don't know if people be prepared for a...stablization
Xeno Amess <xe...@gmail.com> 于2025年5月29日周四 17:21写道：
> all running with skipTests
>
> log4j both success, mvn3 2:00 mvn4 1:50
> dubbo both success, mvn3 3:08 mvn4 3:19
>
> hadoop failed due to network reason(for yarn frontend, well considering
> about where I'm living it is normal...)
>
> for structs 2, 90%+ time is wasted on antrun for docs generation in
> struts2-assembly. both mvn3 and mvn4 be very very slow there.
>
>
> jetty seems has profile-plugin leak when using mvn4.
> maven-assembly-plugin:3.7.1 wrongly invoking a bom sub-project, which is
> only defined in a profile (named `config`) which shall not be on.
>
> quarkus cannot build with mvn4, maven-invoker-plugin failed
>
> Xeno Amess <xe...@gmail.com> 于2025年5月29日周四 14:52写道：
>
>> nope. neither can the github master latest.
>>
>> Xeno Amess <xe...@gmail.com> 于2025年5月29日周四 14:40写道：
>>
>>> I used apache-maven-4.0.0-rc-3 btw. I would have a try at the latest
>>> github code version...
>>>
>>> Xeno Amess <xe...@gmail.com> 于2025年5月29日周四 14:39写道：
>>>
>>>> jetty is a good example.
>>>> mvn3 can build but mvn4 cannot.
>>>>
>>>> maven-assembly-plugin:3.7.1 wrongly invoking a bom sub-project
>>>>
>>>> [INFO] ---------------< org.eclipse.jetty.ee10:jetty-ee10-bom
>>>> >----------------
>>>> [INFO] Building EE10 :: BOM 12.0.22-SNAPSHOT
>>>> [90/354]
>>>> [INFO] from jetty-ee10/jetty-ee10-bom/pom.xml
>>>> [INFO] --------------------------------[ pom
>>>> ]---------------------------------
>>>> [INFO] Going to calculate checksum for project
>>>> [groupId=org.eclipse.jetty.ee10, artifactId=jetty-ee10-bom,
>>>> version=12.0.22-SNAPSHOT]
>>>> [INFO] Project inputs calculated in 0 ms. XXMM checksum
>>>> [7b7b6120251dfd1d] calculated in 0 ms.
>>>> [INFO] Attempting to restore project
>>>> org.eclipse.jetty.ee10:jetty-ee10-bom from build cache
>>>> [INFO] Local build found by checksum 7b7b6120251dfd1d
>>>> [INFO] Found cached build, restoring
>>>> org.eclipse.jetty.ee10:jetty-ee10-bom from cache by checksum
>>>> 7b7b6120251dfd1d
>>>> [WARNING] Cached build doesn't contains all requested plugin executions
>>>> (missing:
>>>> [org.apache.maven.plugins:maven-resources-plugin:3.3.1:copy-resources
>>>> {execution: copy-resources},
>>>> org.apache.maven.plugins:maven-assembly-plugin:3.7.1:single {execution:
>>>> config-assembly}]), cannot restore
>>>> [INFO] Local build was not found by checksum 7b7b6120251dfd1d for
>>>> org.eclipse.jetty.ee10:jetty-ee10-bom
>>>> [INFO]
>>>> [INFO] --- spotless:2.44.4:check (default) @ jetty-ee10-bom ---
>>>> [INFO] Index file does not exist. Fallback to an empty index
>>>> [INFO] Sorting file /tmp/pom11239457262347372795.xml
>>>> [INFO] Pom file is already sorted, exiting
>>>> [INFO] Spotless.Pom is keeping 1 files clean - 0 needs changes to be
>>>> clean, 1 were already clean, 0 were skipped because caching determined they
>>>> were already clean
>>>> [INFO]
>>>> [INFO] --- checkstyle:3.6.0:check (checkstyle-check) @ jetty-ee10-bom
>>>> ---
>>>> [INFO] 开始检查……
>>>> 检查完成。
>>>> [INFO] You have 0 Checkstyle violations.
>>>> [INFO]
>>>> [INFO] --- enforcer:3.5.0:enforce (ban-javax-servlet-api) @
>>>> jetty-ee10-bom ---
>>>> [INFO] Rule 0:
>>>> org.apache.maven.enforcer.rules.dependency.BannedDependencies passed
>>>> [INFO]
>>>> [INFO] --- enforcer:3.5.0:enforce (enforce-java) @ jetty-ee10-bom ---
>>>> [INFO] Rule 3:
>>>> org.eclipse.jetty.toolchain.enforcer.rules.RequireOsgiCompatibleVersionRule(versionOsgiRule)
>>>> passed
>>>> [INFO] Rule 4:
>>>> org.apache.maven.enforcer.rules.dependency.RequireUpperBoundDeps passed
>>>> [INFO]
>>>> [INFO] --- build-helper:3.6.0:parse-version (set-osgi-version) @
>>>> jetty-ee10-bom ---
>>>> [INFO]
>>>> [INFO] --- jacoco:0.8.13:prepare-agent (jacoco-initialize) @
>>>> jetty-ee10-bom ---
>>>> [INFO] argLine set to
>>>> -javaagent:/home/xenoamess/.m2/repository/org/jacoco/org.jacoco.agent/0.8.13/org.jacoco.agent-0.8.13-runtime.jar=destfile=/home/xenoamess/workspace/jetty.project/jetty-ee10/jetty-ee10-bom/target/jacoco.exec,excludes=**/org/eclipse/jetty/ant/**:*/org/eclipse/jetty/maven/its/**:**/org/eclipse/jetty/embedded/**:**/org/eclipse/jetty/asyncrest/**:**/org/eclipse/jetty/demo/**:**/org/eclipse/jetty/gcloud/**:**/org/eclipse/jetty/infinispan/**:**/org/eclipse/jetty/osgi/**:**/org/eclipse/jetty/spring/**:**/org/eclipse/jetty/http/spi/**:**/org/eclipse/jetty/tests/**:**/org/eclipse/jetty/test/**
>>>> [INFO]
>>>> [INFO] --- jacoco:0.8.13:prepare-agent (jacoco-setup-m-invoker-p) @
>>>> jetty-ee10-bom ---
>>>> [INFO] invoker.mavenOpts set to
>>>> -javaagent:/home/xenoamess/.m2/repository/org/jacoco/org.jacoco.agent/0.8.13/org.jacoco.agent-0.8.13-runtime.jar=destfile=/home/xenoamess/workspace/jetty.project/jetty-ee10/jetty-ee10-bom/target/jacoco.exec,excludes=**/org/eclipse/jetty/ant/**:*/org/eclipse/jetty/maven/its/**:**/org/eclipse/jetty/embedded/**:**/org/eclipse/jetty/asyncrest/**:**/org/eclipse/jetty/demo/**:**/org/eclipse/jetty/gcloud/**:**/org/eclipse/jetty/infinispan/**:**/org/eclipse/jetty/osgi/**:**/org/eclipse/jetty/spring/**:**/org/eclipse/jetty/http/spi/**:**/org/eclipse/jetty/tests/**:**/org/eclipse/jetty/test/**
>>>> [INFO]
>>>> [INFO] --- remote-resources:3.2.0:process (copy-shared-resources) @
>>>> jetty-ee10-bom ---
>>>> [INFO] Preparing remote bundle
>>>> org.eclipse.jetty:build-resources:12.0.22-SNAPSHOT
>>>> [INFO] Copying 0 resource from 1 bundle.
>>>> [INFO]
>>>> [INFO] --- jetty-version:2.7:attach-version-text (attach-version) @
>>>> jetty-ee10-bom ---
>>>> [INFO]
>>>> [INFO] --- resources:3.3.1:copy-resources (copy-resources) @
>>>> jetty-ee10-bom ---
>>>> [INFO] skip non existing resourceDirectory
>>>> /home/xenoamess/workspace/jetty.project/jetty-ee10/jetty-ee10-bom/src/main/config
>>>> [INFO]
>>>> [INFO] --- flatten:1.7.0:flatten (flatten) @ jetty-ee10-bom ---
>>>> [INFO] Generating flattened POM of project
>>>> org.eclipse.jetty.ee10:jetty-ee10-bom:pom:12.0.22-SNAPSHOT...
>>>> [INFO]
>>>> [INFO] --- bundle:5.1.9:manifest (default) @ jetty-ee10-bom ---
>>>> [WARNING] Ignoring project type pom - supportedProjectTypes = [jar,
>>>> maven-plugin]
>>>> [INFO]
>>>> [INFO] --- source:3.3.1:jar-no-fork (attach-sources) @ jetty-ee10-bom
>>>> ---
>>>> [INFO]
>>>> [INFO] --- jacoco:0.8.13:report (jacoco-site) @ jetty-ee10-bom ---
>>>> [INFO] Skipping JaCoCo execution due to missing execution data file.
>>>> [INFO]
>>>> [INFO] --- assembly:3.7.1:single (config-assembly) @ jetty-ee10-bom ---
>>>>
>>>>
>>>>
>>>> [INFO] Mimir session closed (RETRIEVED=0 CACHED=0)
>>>> [ERROR] Failed to execute goal
>>>> org.apache.maven.plugins:maven-assembly-plugin:3.7.1:single
>>>> (config-assembly) on project jetty-ee10-bom: Failed to create assembly:
>>>> Error creating assembly archive config: archive cannot be empty -> [Help 1]
>>>> [ERROR]
>>>>
>>>>
>>>> checked it did not invoke in mvn3 building log...
>>>>
>>>> Sergey Chernov <se...@gmail.com> 于2025年5月29日周四 00:17写道：
>>>>
>>>>> Hey, Delany. I will look into this.
>>>>> Also to avoid confusion let's continue this discussion in the proper
>>>>> thread
>>>>> as it's not related to maven 4 release
>>>>>
>>>>> On Wed, May 28, 2025 at 4:22 PM Delany <de...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> > Hi Sergei,
>>>>> >
>>>>> > I'm running with this extension going forward. I don't use the build
>>>>> cache
>>>>> > (yet) so that's not an issue.
>>>>> > When trying to promote unit tests to a company that's resistant its
>>>>> helpful
>>>>> > to be able to say the tests won't slow down the build.
>>>>> >
>>>>> > We have one huge module though (project we're calling it now) with
>>>>> > extensive tests, and its a bottleneck for all that follow.
>>>>> > Typically we had to skip tests, but now we don't have to. Build time
>>>>> was
>>>>> > cut in half.
>>>>> >
>>>>> > I did notice jacoco coverage was disabled as I bound the
>>>>> > jacoco-maven-plugin report goal to the prepare-package phase.
>>>>> > As the documentation says, the phases have been switched around.
>>>>> > But can you make it work with the buildplan-maven-plugin:list-phases
>>>>> goal
>>>>> > so I can actually see which phases runs when, or is that up to this
>>>>> plugin
>>>>> > to figure out?
>>>>> >
>>>>> > Kind regards,
>>>>> > Delany
>>>>> >
>>>>> >
>>>>> > On Wed, 28 May 2025 at 14:55, Sergey Chernov <serega.morph@gmail.com
>>>>> >
>>>>> > wrote:
>>>>> >
>>>>> > > Guillaume, that's awesome. It's good that there is no rush with it.
>>>>> > > Once I'll have insights, I'll share them.
>>>>> > >
>>>>> > > Xeno, the project I'm checking is private unfortunately. Also this
>>>>> can be
>>>>> > > quite challenging to find a good Maven multi-module project as a
>>>>> > reference
>>>>> > > for performance testing and compatibility validations, as many of
>>>>> big
>>>>> > > projects e.g. have flaky tests and other issues.
>>>>> > > Some of the biggest that I've seen:
>>>>> > > * https://github.com/quarkusio/quarkus (has lots of
>>>>> customizations in
>>>>> > > .mvn/extensions.xml)
>>>>> > > * https://github.com/apache/dubbo
>>>>> > > * https://github.com/apache/hadoop
>>>>> > > * https://github.com/apache/struts
>>>>> > > * https://github.com/vaadin/flow and
>>>>> https://github.com/vaadin/framework
>>>>> > >
>>>>> > >
>>>>> > > On Wed, May 28, 2025 at 2:16 PM Guillaume Nodet <gnodet@apache.org
>>>>> >
>>>>> > wrote:
>>>>> > >
>>>>> > > > After considering the concerns about API stability, plugin
>>>>> > > > compatibility, and the performance issues reported by Sergey (4x
>>>>> > > > slower in rc3), I agree with Sylwester, Benjamin, and Elliotte
>>>>> that we
>>>>> > > > should opt for an rc4 to address these issues. My proposal is to
>>>>> > > > release a final release candidate (rc4) soon, aiming for a
>>>>> General
>>>>> > > > Availability (GA) release in September. Post rc4, I suggest
>>>>> creating a
>>>>> > > > 4.0.x branch to start work on 4.1.0. For 4.1.0, we could
>>>>> introduce API
>>>>> > > > changes like records and sequenced collections, as well as new
>>>>> > > > features such as mixins, cascading profiles, server aliases, JDK
>>>>> 21
>>>>> > > > (still under discussion) and more....
>>>>> > > >
>>>>> > > > The recent API changes for JPMS, as Martin noted, only affect the
>>>>> > > > experimental API, so they shouldn’t block the release. On
>>>>> Matthias’s
>>>>> > > > suggestion, enabling GitHub Issues across all repositories
>>>>> before the
>>>>> > > > GA seems like a good idea to improve user feedback. Let’s focus
>>>>> on
>>>>> > > > stabilizing rc4 and addressing performance bottlenecks, possibly
>>>>> > > > exploring Martin’s O(N²) concerns with profiling, as Sergey
>>>>> offered.
>>>>> > > >
>>>>> > > > What do you think about this plan?
>>>>> > > >
>>>>> > > > On a side note, I created a few months ago a project to check
>>>>> Maven 4
>>>>> > > > compatibility with all Apache projects using Maven. The results
>>>>> for
>>>>> > > > RC-3 can be found at
>>>>> > > > https://github.com/gnodet/maven4-testing/issues/2812. Most of
>>>>> the
>>>>> > > > errors are caused by the use of incompatible plugins (which
>>>>> needs to
>>>>> > > > be updated) or incorrect POMs (as Maven 4 is more strict about a
>>>>> few
>>>>> > > > things). What would be nice is a tool to integrate in the shell
>>>>> that
>>>>> > > > would fix those known incompatibilities, so that users would
>>>>> have an
>>>>> > > > easier migration path. And we could apply it to this project to
>>>>> make
>>>>> > > > more green boxes.
>>>>> > > >
>>>>> > > > Le mer. 21 mai 2025 à 08:11, Guillaume Nodet <gn...@apache.org>
>>>>> a
>>>>> > > écrit :
>>>>> > > > >
>>>>> > > > > Hey Maven Devs,
>>>>> > > > >
>>>>> > > > > We're gearing up to release a new version from the master
>>>>> branch. I'm
>>>>> > > > thinking we should go for 4.0.0 instead of rc-4. What do you all
>>>>> think?
>>>>> > > Any
>>>>> > > > feedback or ideas on the versioning or release plan? Let’s hear
>>>>> it!
>>>>> > > > >
>>>>> > > > > Cheers,
>>>>> > > > >
>>>>> > > > > Guillaume
>>>>> > > > >
>>>>> > > > >
>>>>> > > >
>>>>> > > >
>>>>> > > > --
>>>>> > > > ------------------------
>>>>> > > > Guillaume Nodet
>>>>> > > >
>>>>> > > >
>>>>> ---------------------------------------------------------------------
>>>>> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> > > > For additional commands, e-mail: dev-help@maven.apache.org
>>>>> > > >
>>>>> > > >
>>>>> > >
>>>>> >
>>>>>
>>>>
Re: Maven 4.0.0 Release - Thoughts?
Posted by Xeno Amess <xe...@gmail.com>.
all running with skipTests
log4j both success, mvn3 2:00 mvn4 1:50
dubbo both success, mvn3 3:08 mvn4 3:19
hadoop failed due to network reason(for yarn frontend, well considering
about where I'm living it is normal...)
for structs 2, 90%+ time is wasted on antrun for docs generation in
struts2-assembly. both mvn3 and mvn4 be very very slow there.
jetty seems has profile-plugin leak when using mvn4.
maven-assembly-plugin:3.7.1 wrongly invoking a bom sub-project, which is
only defined in a profile (named `config`) which shall not be on.
quarkus cannot build with mvn4, maven-invoker-plugin failed
Xeno Amess <xe...@gmail.com> 于2025年5月29日周四 14:52写道：
> nope. neither can the github master latest.
>
> Xeno Amess <xe...@gmail.com> 于2025年5月29日周四 14:40写道：
>
>> I used apache-maven-4.0.0-rc-3 btw. I would have a try at the latest
>> github code version...
>>
>> Xeno Amess <xe...@gmail.com> 于2025年5月29日周四 14:39写道：
>>
>>> jetty is a good example.
>>> mvn3 can build but mvn4 cannot.
>>>
>>> maven-assembly-plugin:3.7.1 wrongly invoking a bom sub-project
>>>
>>> [INFO] ---------------< org.eclipse.jetty.ee10:jetty-ee10-bom
>>> >----------------
>>> [INFO] Building EE10 :: BOM 12.0.22-SNAPSHOT
>>> [90/354]
>>> [INFO] from jetty-ee10/jetty-ee10-bom/pom.xml
>>> [INFO] --------------------------------[ pom
>>> ]---------------------------------
>>> [INFO] Going to calculate checksum for project
>>> [groupId=org.eclipse.jetty.ee10, artifactId=jetty-ee10-bom,
>>> version=12.0.22-SNAPSHOT]
>>> [INFO] Project inputs calculated in 0 ms. XXMM checksum
>>> [7b7b6120251dfd1d] calculated in 0 ms.
>>> [INFO] Attempting to restore project
>>> org.eclipse.jetty.ee10:jetty-ee10-bom from build cache
>>> [INFO] Local build found by checksum 7b7b6120251dfd1d
>>> [INFO] Found cached build, restoring
>>> org.eclipse.jetty.ee10:jetty-ee10-bom from cache by checksum
>>> 7b7b6120251dfd1d
>>> [WARNING] Cached build doesn't contains all requested plugin executions
>>> (missing:
>>> [org.apache.maven.plugins:maven-resources-plugin:3.3.1:copy-resources
>>> {execution: copy-resources},
>>> org.apache.maven.plugins:maven-assembly-plugin:3.7.1:single {execution:
>>> config-assembly}]), cannot restore
>>> [INFO] Local build was not found by checksum 7b7b6120251dfd1d for
>>> org.eclipse.jetty.ee10:jetty-ee10-bom
>>> [INFO]
>>> [INFO] --- spotless:2.44.4:check (default) @ jetty-ee10-bom ---
>>> [INFO] Index file does not exist. Fallback to an empty index
>>> [INFO] Sorting file /tmp/pom11239457262347372795.xml
>>> [INFO] Pom file is already sorted, exiting
>>> [INFO] Spotless.Pom is keeping 1 files clean - 0 needs changes to be
>>> clean, 1 were already clean, 0 were skipped because caching determined they
>>> were already clean
>>> [INFO]
>>> [INFO] --- checkstyle:3.6.0:check (checkstyle-check) @ jetty-ee10-bom ---
>>> [INFO] 开始检查……
>>> 检查完成。
>>> [INFO] You have 0 Checkstyle violations.
>>> [INFO]
>>> [INFO] --- enforcer:3.5.0:enforce (ban-javax-servlet-api) @
>>> jetty-ee10-bom ---
>>> [INFO] Rule 0:
>>> org.apache.maven.enforcer.rules.dependency.BannedDependencies passed
>>> [INFO]
>>> [INFO] --- enforcer:3.5.0:enforce (enforce-java) @ jetty-ee10-bom ---
>>> [INFO] Rule 3:
>>> org.eclipse.jetty.toolchain.enforcer.rules.RequireOsgiCompatibleVersionRule(versionOsgiRule)
>>> passed
>>> [INFO] Rule 4:
>>> org.apache.maven.enforcer.rules.dependency.RequireUpperBoundDeps passed
>>> [INFO]
>>> [INFO] --- build-helper:3.6.0:parse-version (set-osgi-version) @
>>> jetty-ee10-bom ---
>>> [INFO]
>>> [INFO] --- jacoco:0.8.13:prepare-agent (jacoco-initialize) @
>>> jetty-ee10-bom ---
>>> [INFO] argLine set to
>>> -javaagent:/home/xenoamess/.m2/repository/org/jacoco/org.jacoco.agent/0.8.13/org.jacoco.agent-0.8.13-runtime.jar=destfile=/home/xenoamess/workspace/jetty.project/jetty-ee10/jetty-ee10-bom/target/jacoco.exec,excludes=**/org/eclipse/jetty/ant/**:*/org/eclipse/jetty/maven/its/**:**/org/eclipse/jetty/embedded/**:**/org/eclipse/jetty/asyncrest/**:**/org/eclipse/jetty/demo/**:**/org/eclipse/jetty/gcloud/**:**/org/eclipse/jetty/infinispan/**:**/org/eclipse/jetty/osgi/**:**/org/eclipse/jetty/spring/**:**/org/eclipse/jetty/http/spi/**:**/org/eclipse/jetty/tests/**:**/org/eclipse/jetty/test/**
>>> [INFO]
>>> [INFO] --- jacoco:0.8.13:prepare-agent (jacoco-setup-m-invoker-p) @
>>> jetty-ee10-bom ---
>>> [INFO] invoker.mavenOpts set to
>>> -javaagent:/home/xenoamess/.m2/repository/org/jacoco/org.jacoco.agent/0.8.13/org.jacoco.agent-0.8.13-runtime.jar=destfile=/home/xenoamess/workspace/jetty.project/jetty-ee10/jetty-ee10-bom/target/jacoco.exec,excludes=**/org/eclipse/jetty/ant/**:*/org/eclipse/jetty/maven/its/**:**/org/eclipse/jetty/embedded/**:**/org/eclipse/jetty/asyncrest/**:**/org/eclipse/jetty/demo/**:**/org/eclipse/jetty/gcloud/**:**/org/eclipse/jetty/infinispan/**:**/org/eclipse/jetty/osgi/**:**/org/eclipse/jetty/spring/**:**/org/eclipse/jetty/http/spi/**:**/org/eclipse/jetty/tests/**:**/org/eclipse/jetty/test/**
>>> [INFO]
>>> [INFO] --- remote-resources:3.2.0:process (copy-shared-resources) @
>>> jetty-ee10-bom ---
>>> [INFO] Preparing remote bundle
>>> org.eclipse.jetty:build-resources:12.0.22-SNAPSHOT
>>> [INFO] Copying 0 resource from 1 bundle.
>>> [INFO]
>>> [INFO] --- jetty-version:2.7:attach-version-text (attach-version) @
>>> jetty-ee10-bom ---
>>> [INFO]
>>> [INFO] --- resources:3.3.1:copy-resources (copy-resources) @
>>> jetty-ee10-bom ---
>>> [INFO] skip non existing resourceDirectory
>>> /home/xenoamess/workspace/jetty.project/jetty-ee10/jetty-ee10-bom/src/main/config
>>> [INFO]
>>> [INFO] --- flatten:1.7.0:flatten (flatten) @ jetty-ee10-bom ---
>>> [INFO] Generating flattened POM of project
>>> org.eclipse.jetty.ee10:jetty-ee10-bom:pom:12.0.22-SNAPSHOT...
>>> [INFO]
>>> [INFO] --- bundle:5.1.9:manifest (default) @ jetty-ee10-bom ---
>>> [WARNING] Ignoring project type pom - supportedProjectTypes = [jar,
>>> maven-plugin]
>>> [INFO]
>>> [INFO] --- source:3.3.1:jar-no-fork (attach-sources) @ jetty-ee10-bom ---
>>> [INFO]
>>> [INFO] --- jacoco:0.8.13:report (jacoco-site) @ jetty-ee10-bom ---
>>> [INFO] Skipping JaCoCo execution due to missing execution data file.
>>> [INFO]
>>> [INFO] --- assembly:3.7.1:single (config-assembly) @ jetty-ee10-bom ---
>>>
>>>
>>>
>>> [INFO] Mimir session closed (RETRIEVED=0 CACHED=0)
>>> [ERROR] Failed to execute goal
>>> org.apache.maven.plugins:maven-assembly-plugin:3.7.1:single
>>> (config-assembly) on project jetty-ee10-bom: Failed to create assembly:
>>> Error creating assembly archive config: archive cannot be empty -> [Help 1]
>>> [ERROR]
>>>
>>>
>>> checked it did not invoke in mvn3 building log...
>>>
>>> Sergey Chernov <se...@gmail.com> 于2025年5月29日周四 00:17写道：
>>>
>>>> Hey, Delany. I will look into this.
>>>> Also to avoid confusion let's continue this discussion in the proper
>>>> thread
>>>> as it's not related to maven 4 release
>>>>
>>>> On Wed, May 28, 2025 at 4:22 PM Delany <de...@gmail.com>
>>>> wrote:
>>>>
>>>> > Hi Sergei,
>>>> >
>>>> > I'm running with this extension going forward. I don't use the build
>>>> cache
>>>> > (yet) so that's not an issue.
>>>> > When trying to promote unit tests to a company that's resistant its
>>>> helpful
>>>> > to be able to say the tests won't slow down the build.
>>>> >
>>>> > We have one huge module though (project we're calling it now) with
>>>> > extensive tests, and its a bottleneck for all that follow.
>>>> > Typically we had to skip tests, but now we don't have to. Build time
>>>> was
>>>> > cut in half.
>>>> >
>>>> > I did notice jacoco coverage was disabled as I bound the
>>>> > jacoco-maven-plugin report goal to the prepare-package phase.
>>>> > As the documentation says, the phases have been switched around.
>>>> > But can you make it work with the buildplan-maven-plugin:list-phases
>>>> goal
>>>> > so I can actually see which phases runs when, or is that up to this
>>>> plugin
>>>> > to figure out?
>>>> >
>>>> > Kind regards,
>>>> > Delany
>>>> >
>>>> >
>>>> > On Wed, 28 May 2025 at 14:55, Sergey Chernov <se...@gmail.com>
>>>> > wrote:
>>>> >
>>>> > > Guillaume, that's awesome. It's good that there is no rush with it.
>>>> > > Once I'll have insights, I'll share them.
>>>> > >
>>>> > > Xeno, the project I'm checking is private unfortunately. Also this
>>>> can be
>>>> > > quite challenging to find a good Maven multi-module project as a
>>>> > reference
>>>> > > for performance testing and compatibility validations, as many of
>>>> big
>>>> > > projects e.g. have flaky tests and other issues.
>>>> > > Some of the biggest that I've seen:
>>>> > > * https://github.com/quarkusio/quarkus (has lots of customizations
>>>> in
>>>> > > .mvn/extensions.xml)
>>>> > > * https://github.com/apache/dubbo
>>>> > > * https://github.com/apache/hadoop
>>>> > > * https://github.com/apache/struts
>>>> > > * https://github.com/vaadin/flow and
>>>> https://github.com/vaadin/framework
>>>> > >
>>>> > >
>>>> > > On Wed, May 28, 2025 at 2:16 PM Guillaume Nodet <gn...@apache.org>
>>>> > wrote:
>>>> > >
>>>> > > > After considering the concerns about API stability, plugin
>>>> > > > compatibility, and the performance issues reported by Sergey (4x
>>>> > > > slower in rc3), I agree with Sylwester, Benjamin, and Elliotte
>>>> that we
>>>> > > > should opt for an rc4 to address these issues. My proposal is to
>>>> > > > release a final release candidate (rc4) soon, aiming for a General
>>>> > > > Availability (GA) release in September. Post rc4, I suggest
>>>> creating a
>>>> > > > 4.0.x branch to start work on 4.1.0. For 4.1.0, we could
>>>> introduce API
>>>> > > > changes like records and sequenced collections, as well as new
>>>> > > > features such as mixins, cascading profiles, server aliases, JDK
>>>> 21
>>>> > > > (still under discussion) and more....
>>>> > > >
>>>> > > > The recent API changes for JPMS, as Martin noted, only affect the
>>>> > > > experimental API, so they shouldn’t block the release. On
>>>> Matthias’s
>>>> > > > suggestion, enabling GitHub Issues across all repositories before
>>>> the
>>>> > > > GA seems like a good idea to improve user feedback. Let’s focus on
>>>> > > > stabilizing rc4 and addressing performance bottlenecks, possibly
>>>> > > > exploring Martin’s O(N²) concerns with profiling, as Sergey
>>>> offered.
>>>> > > >
>>>> > > > What do you think about this plan?
>>>> > > >
>>>> > > > On a side note, I created a few months ago a project to check
>>>> Maven 4
>>>> > > > compatibility with all Apache projects using Maven. The results
>>>> for
>>>> > > > RC-3 can be found at
>>>> > > > https://github.com/gnodet/maven4-testing/issues/2812. Most of
>>>> the
>>>> > > > errors are caused by the use of incompatible plugins (which needs
>>>> to
>>>> > > > be updated) or incorrect POMs (as Maven 4 is more strict about a
>>>> few
>>>> > > > things). What would be nice is a tool to integrate in the shell
>>>> that
>>>> > > > would fix those known incompatibilities, so that users would have
>>>> an
>>>> > > > easier migration path. And we could apply it to this project to
>>>> make
>>>> > > > more green boxes.
>>>> > > >
>>>> > > > Le mer. 21 mai 2025 à 08:11, Guillaume Nodet <gn...@apache.org>
>>>> a
>>>> > > écrit :
>>>> > > > >
>>>> > > > > Hey Maven Devs,
>>>> > > > >
>>>> > > > > We're gearing up to release a new version from the master
>>>> branch. I'm
>>>> > > > thinking we should go for 4.0.0 instead of rc-4. What do you all
>>>> think?
>>>> > > Any
>>>> > > > feedback or ideas on the versioning or release plan? Let’s hear
>>>> it!
>>>> > > > >
>>>> > > > > Cheers,
>>>> > > > >
>>>> > > > > Guillaume
>>>> > > > >
>>>> > > > >
>>>> > > >
>>>> > > >
>>>> > > > --
>>>> > > > ------------------------
>>>> > > > Guillaume Nodet
>>>> > > >
>>>> > > >
>>>> ---------------------------------------------------------------------
>>>> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> > > > For additional commands, e-mail: dev-help@maven.apache.org
>>>> > > >
>>>> > > >
>>>> > >
>>>> >
>>>>
>>>
Re: Maven 4.0.0 Release - Thoughts?
Posted by Xeno Amess <xe...@gmail.com>.
nope. neither can the github master latest.
Xeno Amess <xe...@gmail.com> 于2025年5月29日周四 14:40写道：
> I used apache-maven-4.0.0-rc-3 btw. I would have a try at the latest
> github code version...
>
> Xeno Amess <xe...@gmail.com> 于2025年5月29日周四 14:39写道：
>
>> jetty is a good example.
>> mvn3 can build but mvn4 cannot.
>>
>> maven-assembly-plugin:3.7.1 wrongly invoking a bom sub-project
>>
>> [INFO] ---------------< org.eclipse.jetty.ee10:jetty-ee10-bom
>> >----------------
>> [INFO] Building EE10 :: BOM 12.0.22-SNAPSHOT
>> [90/354]
>> [INFO] from jetty-ee10/jetty-ee10-bom/pom.xml
>> [INFO] --------------------------------[ pom
>> ]---------------------------------
>> [INFO] Going to calculate checksum for project
>> [groupId=org.eclipse.jetty.ee10, artifactId=jetty-ee10-bom,
>> version=12.0.22-SNAPSHOT]
>> [INFO] Project inputs calculated in 0 ms. XXMM checksum
>> [7b7b6120251dfd1d] calculated in 0 ms.
>> [INFO] Attempting to restore project
>> org.eclipse.jetty.ee10:jetty-ee10-bom from build cache
>> [INFO] Local build found by checksum 7b7b6120251dfd1d
>> [INFO] Found cached build, restoring
>> org.eclipse.jetty.ee10:jetty-ee10-bom from cache by checksum
>> 7b7b6120251dfd1d
>> [WARNING] Cached build doesn't contains all requested plugin executions
>> (missing:
>> [org.apache.maven.plugins:maven-resources-plugin:3.3.1:copy-resources
>> {execution: copy-resources},
>> org.apache.maven.plugins:maven-assembly-plugin:3.7.1:single {execution:
>> config-assembly}]), cannot restore
>> [INFO] Local build was not found by checksum 7b7b6120251dfd1d for
>> org.eclipse.jetty.ee10:jetty-ee10-bom
>> [INFO]
>> [INFO] --- spotless:2.44.4:check (default) @ jetty-ee10-bom ---
>> [INFO] Index file does not exist. Fallback to an empty index
>> [INFO] Sorting file /tmp/pom11239457262347372795.xml
>> [INFO] Pom file is already sorted, exiting
>> [INFO] Spotless.Pom is keeping 1 files clean - 0 needs changes to be
>> clean, 1 were already clean, 0 were skipped because caching determined they
>> were already clean
>> [INFO]
>> [INFO] --- checkstyle:3.6.0:check (checkstyle-check) @ jetty-ee10-bom ---
>> [INFO] 开始检查……
>> 检查完成。
>> [INFO] You have 0 Checkstyle violations.
>> [INFO]
>> [INFO] --- enforcer:3.5.0:enforce (ban-javax-servlet-api) @
>> jetty-ee10-bom ---
>> [INFO] Rule 0:
>> org.apache.maven.enforcer.rules.dependency.BannedDependencies passed
>> [INFO]
>> [INFO] --- enforcer:3.5.0:enforce (enforce-java) @ jetty-ee10-bom ---
>> [INFO] Rule 3:
>> org.eclipse.jetty.toolchain.enforcer.rules.RequireOsgiCompatibleVersionRule(versionOsgiRule)
>> passed
>> [INFO] Rule 4:
>> org.apache.maven.enforcer.rules.dependency.RequireUpperBoundDeps passed
>> [INFO]
>> [INFO] --- build-helper:3.6.0:parse-version (set-osgi-version) @
>> jetty-ee10-bom ---
>> [INFO]
>> [INFO] --- jacoco:0.8.13:prepare-agent (jacoco-initialize) @
>> jetty-ee10-bom ---
>> [INFO] argLine set to
>> -javaagent:/home/xenoamess/.m2/repository/org/jacoco/org.jacoco.agent/0.8.13/org.jacoco.agent-0.8.13-runtime.jar=destfile=/home/xenoamess/workspace/jetty.project/jetty-ee10/jetty-ee10-bom/target/jacoco.exec,excludes=**/org/eclipse/jetty/ant/**:*/org/eclipse/jetty/maven/its/**:**/org/eclipse/jetty/embedded/**:**/org/eclipse/jetty/asyncrest/**:**/org/eclipse/jetty/demo/**:**/org/eclipse/jetty/gcloud/**:**/org/eclipse/jetty/infinispan/**:**/org/eclipse/jetty/osgi/**:**/org/eclipse/jetty/spring/**:**/org/eclipse/jetty/http/spi/**:**/org/eclipse/jetty/tests/**:**/org/eclipse/jetty/test/**
>> [INFO]
>> [INFO] --- jacoco:0.8.13:prepare-agent (jacoco-setup-m-invoker-p) @
>> jetty-ee10-bom ---
>> [INFO] invoker.mavenOpts set to
>> -javaagent:/home/xenoamess/.m2/repository/org/jacoco/org.jacoco.agent/0.8.13/org.jacoco.agent-0.8.13-runtime.jar=destfile=/home/xenoamess/workspace/jetty.project/jetty-ee10/jetty-ee10-bom/target/jacoco.exec,excludes=**/org/eclipse/jetty/ant/**:*/org/eclipse/jetty/maven/its/**:**/org/eclipse/jetty/embedded/**:**/org/eclipse/jetty/asyncrest/**:**/org/eclipse/jetty/demo/**:**/org/eclipse/jetty/gcloud/**:**/org/eclipse/jetty/infinispan/**:**/org/eclipse/jetty/osgi/**:**/org/eclipse/jetty/spring/**:**/org/eclipse/jetty/http/spi/**:**/org/eclipse/jetty/tests/**:**/org/eclipse/jetty/test/**
>> [INFO]
>> [INFO] --- remote-resources:3.2.0:process (copy-shared-resources) @
>> jetty-ee10-bom ---
>> [INFO] Preparing remote bundle
>> org.eclipse.jetty:build-resources:12.0.22-SNAPSHOT
>> [INFO] Copying 0 resource from 1 bundle.
>> [INFO]
>> [INFO] --- jetty-version:2.7:attach-version-text (attach-version) @
>> jetty-ee10-bom ---
>> [INFO]
>> [INFO] --- resources:3.3.1:copy-resources (copy-resources) @
>> jetty-ee10-bom ---
>> [INFO] skip non existing resourceDirectory
>> /home/xenoamess/workspace/jetty.project/jetty-ee10/jetty-ee10-bom/src/main/config
>> [INFO]
>> [INFO] --- flatten:1.7.0:flatten (flatten) @ jetty-ee10-bom ---
>> [INFO] Generating flattened POM of project
>> org.eclipse.jetty.ee10:jetty-ee10-bom:pom:12.0.22-SNAPSHOT...
>> [INFO]
>> [INFO] --- bundle:5.1.9:manifest (default) @ jetty-ee10-bom ---
>> [WARNING] Ignoring project type pom - supportedProjectTypes = [jar,
>> maven-plugin]
>> [INFO]
>> [INFO] --- source:3.3.1:jar-no-fork (attach-sources) @ jetty-ee10-bom ---
>> [INFO]
>> [INFO] --- jacoco:0.8.13:report (jacoco-site) @ jetty-ee10-bom ---
>> [INFO] Skipping JaCoCo execution due to missing execution data file.
>> [INFO]
>> [INFO] --- assembly:3.7.1:single (config-assembly) @ jetty-ee10-bom ---
>>
>>
>>
>> [INFO] Mimir session closed (RETRIEVED=0 CACHED=0)
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-assembly-plugin:3.7.1:single
>> (config-assembly) on project jetty-ee10-bom: Failed to create assembly:
>> Error creating assembly archive config: archive cannot be empty -> [Help 1]
>> [ERROR]
>>
>>
>> checked it did not invoke in mvn3 building log...
>>
>> Sergey Chernov <se...@gmail.com> 于2025年5月29日周四 00:17写道：
>>
>>> Hey, Delany. I will look into this.
>>> Also to avoid confusion let's continue this discussion in the proper
>>> thread
>>> as it's not related to maven 4 release
>>>
>>> On Wed, May 28, 2025 at 4:22 PM Delany <de...@gmail.com>
>>> wrote:
>>>
>>> > Hi Sergei,
>>> >
>>> > I'm running with this extension going forward. I don't use the build
>>> cache
>>> > (yet) so that's not an issue.
>>> > When trying to promote unit tests to a company that's resistant its
>>> helpful
>>> > to be able to say the tests won't slow down the build.
>>> >
>>> > We have one huge module though (project we're calling it now) with
>>> > extensive tests, and its a bottleneck for all that follow.
>>> > Typically we had to skip tests, but now we don't have to. Build time
>>> was
>>> > cut in half.
>>> >
>>> > I did notice jacoco coverage was disabled as I bound the
>>> > jacoco-maven-plugin report goal to the prepare-package phase.
>>> > As the documentation says, the phases have been switched around.
>>> > But can you make it work with the buildplan-maven-plugin:list-phases
>>> goal
>>> > so I can actually see which phases runs when, or is that up to this
>>> plugin
>>> > to figure out?
>>> >
>>> > Kind regards,
>>> > Delany
>>> >
>>> >
>>> > On Wed, 28 May 2025 at 14:55, Sergey Chernov <se...@gmail.com>
>>> > wrote:
>>> >
>>> > > Guillaume, that's awesome. It's good that there is no rush with it.
>>> > > Once I'll have insights, I'll share them.
>>> > >
>>> > > Xeno, the project I'm checking is private unfortunately. Also this
>>> can be
>>> > > quite challenging to find a good Maven multi-module project as a
>>> > reference
>>> > > for performance testing and compatibility validations, as many of big
>>> > > projects e.g. have flaky tests and other issues.
>>> > > Some of the biggest that I've seen:
>>> > > * https://github.com/quarkusio/quarkus (has lots of customizations
>>> in
>>> > > .mvn/extensions.xml)
>>> > > * https://github.com/apache/dubbo
>>> > > * https://github.com/apache/hadoop
>>> > > * https://github.com/apache/struts
>>> > > * https://github.com/vaadin/flow and
>>> https://github.com/vaadin/framework
>>> > >
>>> > >
>>> > > On Wed, May 28, 2025 at 2:16 PM Guillaume Nodet <gn...@apache.org>
>>> > wrote:
>>> > >
>>> > > > After considering the concerns about API stability, plugin
>>> > > > compatibility, and the performance issues reported by Sergey (4x
>>> > > > slower in rc3), I agree with Sylwester, Benjamin, and Elliotte
>>> that we
>>> > > > should opt for an rc4 to address these issues. My proposal is to
>>> > > > release a final release candidate (rc4) soon, aiming for a General
>>> > > > Availability (GA) release in September. Post rc4, I suggest
>>> creating a
>>> > > > 4.0.x branch to start work on 4.1.0. For 4.1.0, we could introduce
>>> API
>>> > > > changes like records and sequenced collections, as well as new
>>> > > > features such as mixins, cascading profiles, server aliases, JDK 21
>>> > > > (still under discussion) and more....
>>> > > >
>>> > > > The recent API changes for JPMS, as Martin noted, only affect the
>>> > > > experimental API, so they shouldn’t block the release. On
>>> Matthias’s
>>> > > > suggestion, enabling GitHub Issues across all repositories before
>>> the
>>> > > > GA seems like a good idea to improve user feedback. Let’s focus on
>>> > > > stabilizing rc4 and addressing performance bottlenecks, possibly
>>> > > > exploring Martin’s O(N²) concerns with profiling, as Sergey
>>> offered.
>>> > > >
>>> > > > What do you think about this plan?
>>> > > >
>>> > > > On a side note, I created a few months ago a project to check
>>> Maven 4
>>> > > > compatibility with all Apache projects using Maven. The results
>>> for
>>> > > > RC-3 can be found at
>>> > > > https://github.com/gnodet/maven4-testing/issues/2812. Most of the
>>> > > > errors are caused by the use of incompatible plugins (which needs
>>> to
>>> > > > be updated) or incorrect POMs (as Maven 4 is more strict about a
>>> few
>>> > > > things). What would be nice is a tool to integrate in the shell
>>> that
>>> > > > would fix those known incompatibilities, so that users would have
>>> an
>>> > > > easier migration path. And we could apply it to this project to
>>> make
>>> > > > more green boxes.
>>> > > >
>>> > > > Le mer. 21 mai 2025 à 08:11, Guillaume Nodet <gn...@apache.org> a
>>> > > écrit :
>>> > > > >
>>> > > > > Hey Maven Devs,
>>> > > > >
>>> > > > > We're gearing up to release a new version from the master
>>> branch. I'm
>>> > > > thinking we should go for 4.0.0 instead of rc-4. What do you all
>>> think?
>>> > > Any
>>> > > > feedback or ideas on the versioning or release plan? Let’s hear it!
>>> > > > >
>>> > > > > Cheers,
>>> > > > >
>>> > > > > Guillaume
>>> > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > > > --
>>> > > > ------------------------
>>> > > > Guillaume Nodet
>>> > > >
>>> > > >
>>> ---------------------------------------------------------------------
>>> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> > > > For additional commands, e-mail: dev-help@maven.apache.org
>>> > > >
>>> > > >
>>> > >
>>> >
>>>
>>
Re: Maven 4.0.0 Release - Thoughts?
Posted by Xeno Amess <xe...@gmail.com>.
I used apache-maven-4.0.0-rc-3 btw. I would have a try at the latest github
code version...
Xeno Amess <xe...@gmail.com> 于2025年5月29日周四 14:39写道：
> jetty is a good example.
> mvn3 can build but mvn4 cannot.
>
> maven-assembly-plugin:3.7.1 wrongly invoking a bom sub-project
>
> [INFO] ---------------< org.eclipse.jetty.ee10:jetty-ee10-bom
> >----------------
> [INFO] Building EE10 :: BOM 12.0.22-SNAPSHOT
> [90/354]
> [INFO] from jetty-ee10/jetty-ee10-bom/pom.xml
> [INFO] --------------------------------[ pom
> ]---------------------------------
> [INFO] Going to calculate checksum for project
> [groupId=org.eclipse.jetty.ee10, artifactId=jetty-ee10-bom,
> version=12.0.22-SNAPSHOT]
> [INFO] Project inputs calculated in 0 ms. XXMM checksum [7b7b6120251dfd1d]
> calculated in 0 ms.
> [INFO] Attempting to restore project org.eclipse.jetty.ee10:jetty-ee10-bom
> from build cache
> [INFO] Local build found by checksum 7b7b6120251dfd1d
> [INFO] Found cached build, restoring org.eclipse.jetty.ee10:jetty-ee10-bom
> from cache by checksum 7b7b6120251dfd1d
> [WARNING] Cached build doesn't contains all requested plugin executions
> (missing:
> [org.apache.maven.plugins:maven-resources-plugin:3.3.1:copy-resources
> {execution: copy-resources},
> org.apache.maven.plugins:maven-assembly-plugin:3.7.1:single {execution:
> config-assembly}]), cannot restore
> [INFO] Local build was not found by checksum 7b7b6120251dfd1d for
> org.eclipse.jetty.ee10:jetty-ee10-bom
> [INFO]
> [INFO] --- spotless:2.44.4:check (default) @ jetty-ee10-bom ---
> [INFO] Index file does not exist. Fallback to an empty index
> [INFO] Sorting file /tmp/pom11239457262347372795.xml
> [INFO] Pom file is already sorted, exiting
> [INFO] Spotless.Pom is keeping 1 files clean - 0 needs changes to be
> clean, 1 were already clean, 0 were skipped because caching determined they
> were already clean
> [INFO]
> [INFO] --- checkstyle:3.6.0:check (checkstyle-check) @ jetty-ee10-bom ---
> [INFO] 开始检查……
> 检查完成。
> [INFO] You have 0 Checkstyle violations.
> [INFO]
> [INFO] --- enforcer:3.5.0:enforce (ban-javax-servlet-api) @ jetty-ee10-bom
> ---
> [INFO] Rule 0:
> org.apache.maven.enforcer.rules.dependency.BannedDependencies passed
> [INFO]
> [INFO] --- enforcer:3.5.0:enforce (enforce-java) @ jetty-ee10-bom ---
> [INFO] Rule 3:
> org.eclipse.jetty.toolchain.enforcer.rules.RequireOsgiCompatibleVersionRule(versionOsgiRule)
> passed
> [INFO] Rule 4:
> org.apache.maven.enforcer.rules.dependency.RequireUpperBoundDeps passed
> [INFO]
> [INFO] --- build-helper:3.6.0:parse-version (set-osgi-version) @
> jetty-ee10-bom ---
> [INFO]
> [INFO] --- jacoco:0.8.13:prepare-agent (jacoco-initialize) @
> jetty-ee10-bom ---
> [INFO] argLine set to
> -javaagent:/home/xenoamess/.m2/repository/org/jacoco/org.jacoco.agent/0.8.13/org.jacoco.agent-0.8.13-runtime.jar=destfile=/home/xenoamess/workspace/jetty.project/jetty-ee10/jetty-ee10-bom/target/jacoco.exec,excludes=**/org/eclipse/jetty/ant/**:*/org/eclipse/jetty/maven/its/**:**/org/eclipse/jetty/embedded/**:**/org/eclipse/jetty/asyncrest/**:**/org/eclipse/jetty/demo/**:**/org/eclipse/jetty/gcloud/**:**/org/eclipse/jetty/infinispan/**:**/org/eclipse/jetty/osgi/**:**/org/eclipse/jetty/spring/**:**/org/eclipse/jetty/http/spi/**:**/org/eclipse/jetty/tests/**:**/org/eclipse/jetty/test/**
> [INFO]
> [INFO] --- jacoco:0.8.13:prepare-agent (jacoco-setup-m-invoker-p) @
> jetty-ee10-bom ---
> [INFO] invoker.mavenOpts set to
> -javaagent:/home/xenoamess/.m2/repository/org/jacoco/org.jacoco.agent/0.8.13/org.jacoco.agent-0.8.13-runtime.jar=destfile=/home/xenoamess/workspace/jetty.project/jetty-ee10/jetty-ee10-bom/target/jacoco.exec,excludes=**/org/eclipse/jetty/ant/**:*/org/eclipse/jetty/maven/its/**:**/org/eclipse/jetty/embedded/**:**/org/eclipse/jetty/asyncrest/**:**/org/eclipse/jetty/demo/**:**/org/eclipse/jetty/gcloud/**:**/org/eclipse/jetty/infinispan/**:**/org/eclipse/jetty/osgi/**:**/org/eclipse/jetty/spring/**:**/org/eclipse/jetty/http/spi/**:**/org/eclipse/jetty/tests/**:**/org/eclipse/jetty/test/**
> [INFO]
> [INFO] --- remote-resources:3.2.0:process (copy-shared-resources) @
> jetty-ee10-bom ---
> [INFO] Preparing remote bundle
> org.eclipse.jetty:build-resources:12.0.22-SNAPSHOT
> [INFO] Copying 0 resource from 1 bundle.
> [INFO]
> [INFO] --- jetty-version:2.7:attach-version-text (attach-version) @
> jetty-ee10-bom ---
> [INFO]
> [INFO] --- resources:3.3.1:copy-resources (copy-resources) @
> jetty-ee10-bom ---
> [INFO] skip non existing resourceDirectory
> /home/xenoamess/workspace/jetty.project/jetty-ee10/jetty-ee10-bom/src/main/config
> [INFO]
> [INFO] --- flatten:1.7.0:flatten (flatten) @ jetty-ee10-bom ---
> [INFO] Generating flattened POM of project
> org.eclipse.jetty.ee10:jetty-ee10-bom:pom:12.0.22-SNAPSHOT...
> [INFO]
> [INFO] --- bundle:5.1.9:manifest (default) @ jetty-ee10-bom ---
> [WARNING] Ignoring project type pom - supportedProjectTypes = [jar,
> maven-plugin]
> [INFO]
> [INFO] --- source:3.3.1:jar-no-fork (attach-sources) @ jetty-ee10-bom ---
> [INFO]
> [INFO] --- jacoco:0.8.13:report (jacoco-site) @ jetty-ee10-bom ---
> [INFO] Skipping JaCoCo execution due to missing execution data file.
> [INFO]
> [INFO] --- assembly:3.7.1:single (config-assembly) @ jetty-ee10-bom ---
>
>
>
> [INFO] Mimir session closed (RETRIEVED=0 CACHED=0)
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-assembly-plugin:3.7.1:single
> (config-assembly) on project jetty-ee10-bom: Failed to create assembly:
> Error creating assembly archive config: archive cannot be empty -> [Help 1]
> [ERROR]
>
>
> checked it did not invoke in mvn3 building log...
>
> Sergey Chernov <se...@gmail.com> 于2025年5月29日周四 00:17写道：
>
>> Hey, Delany. I will look into this.
>> Also to avoid confusion let's continue this discussion in the proper
>> thread
>> as it's not related to maven 4 release
>>
>> On Wed, May 28, 2025 at 4:22 PM Delany <de...@gmail.com>
>> wrote:
>>
>> > Hi Sergei,
>> >
>> > I'm running with this extension going forward. I don't use the build
>> cache
>> > (yet) so that's not an issue.
>> > When trying to promote unit tests to a company that's resistant its
>> helpful
>> > to be able to say the tests won't slow down the build.
>> >
>> > We have one huge module though (project we're calling it now) with
>> > extensive tests, and its a bottleneck for all that follow.
>> > Typically we had to skip tests, but now we don't have to. Build time was
>> > cut in half.
>> >
>> > I did notice jacoco coverage was disabled as I bound the
>> > jacoco-maven-plugin report goal to the prepare-package phase.
>> > As the documentation says, the phases have been switched around.
>> > But can you make it work with the buildplan-maven-plugin:list-phases
>> goal
>> > so I can actually see which phases runs when, or is that up to this
>> plugin
>> > to figure out?
>> >
>> > Kind regards,
>> > Delany
>> >
>> >
>> > On Wed, 28 May 2025 at 14:55, Sergey Chernov <se...@gmail.com>
>> > wrote:
>> >
>> > > Guillaume, that's awesome. It's good that there is no rush with it.
>> > > Once I'll have insights, I'll share them.
>> > >
>> > > Xeno, the project I'm checking is private unfortunately. Also this
>> can be
>> > > quite challenging to find a good Maven multi-module project as a
>> > reference
>> > > for performance testing and compatibility validations, as many of big
>> > > projects e.g. have flaky tests and other issues.
>> > > Some of the biggest that I've seen:
>> > > * https://github.com/quarkusio/quarkus (has lots of customizations in
>> > > .mvn/extensions.xml)
>> > > * https://github.com/apache/dubbo
>> > > * https://github.com/apache/hadoop
>> > > * https://github.com/apache/struts
>> > > * https://github.com/vaadin/flow and
>> https://github.com/vaadin/framework
>> > >
>> > >
>> > > On Wed, May 28, 2025 at 2:16 PM Guillaume Nodet <gn...@apache.org>
>> > wrote:
>> > >
>> > > > After considering the concerns about API stability, plugin
>> > > > compatibility, and the performance issues reported by Sergey (4x
>> > > > slower in rc3), I agree with Sylwester, Benjamin, and Elliotte that
>> we
>> > > > should opt for an rc4 to address these issues. My proposal is to
>> > > > release a final release candidate (rc4) soon, aiming for a General
>> > > > Availability (GA) release in September. Post rc4, I suggest
>> creating a
>> > > > 4.0.x branch to start work on 4.1.0. For 4.1.0, we could introduce
>> API
>> > > > changes like records and sequenced collections, as well as new
>> > > > features such as mixins, cascading profiles, server aliases, JDK 21
>> > > > (still under discussion) and more....
>> > > >
>> > > > The recent API changes for JPMS, as Martin noted, only affect the
>> > > > experimental API, so they shouldn’t block the release. On Matthias’s
>> > > > suggestion, enabling GitHub Issues across all repositories before
>> the
>> > > > GA seems like a good idea to improve user feedback. Let’s focus on
>> > > > stabilizing rc4 and addressing performance bottlenecks, possibly
>> > > > exploring Martin’s O(N²) concerns with profiling, as Sergey offered.
>> > > >
>> > > > What do you think about this plan?
>> > > >
>> > > > On a side note, I created a few months ago a project to check Maven
>> 4
>> > > > compatibility with all Apache projects using Maven. The results for
>> > > > RC-3 can be found at
>> > > > https://github.com/gnodet/maven4-testing/issues/2812. Most of the
>> > > > errors are caused by the use of incompatible plugins (which needs to
>> > > > be updated) or incorrect POMs (as Maven 4 is more strict about a few
>> > > > things). What would be nice is a tool to integrate in the shell
>> that
>> > > > would fix those known incompatibilities, so that users would have an
>> > > > easier migration path. And we could apply it to this project to
>> make
>> > > > more green boxes.
>> > > >
>> > > > Le mer. 21 mai 2025 à 08:11, Guillaume Nodet <gn...@apache.org> a
>> > > écrit :
>> > > > >
>> > > > > Hey Maven Devs,
>> > > > >
>> > > > > We're gearing up to release a new version from the master branch.
>> I'm
>> > > > thinking we should go for 4.0.0 instead of rc-4. What do you all
>> think?
>> > > Any
>> > > > feedback or ideas on the versioning or release plan? Let’s hear it!
>> > > > >
>> > > > > Cheers,
>> > > > >
>> > > > > Guillaume
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > > > --
>> > > > ------------------------
>> > > > Guillaume Nodet
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > > > For additional commands, e-mail: dev-help@maven.apache.org
>> > > >
>> > > >
>> > >
>> >
>>
>
Re: Maven 4.0.0 Release - Thoughts?
Posted by Xeno Amess <xe...@gmail.com>.
jetty is a good example.
mvn3 can build but mvn4 cannot.
maven-assembly-plugin:3.7.1 wrongly invoking a bom sub-project
[INFO] ---------------< org.eclipse.jetty.ee10:jetty-ee10-bom
>----------------
[INFO] Building EE10 :: BOM 12.0.22-SNAPSHOT
[90/354]
[INFO] from jetty-ee10/jetty-ee10-bom/pom.xml
[INFO] --------------------------------[ pom
]---------------------------------
[INFO] Going to calculate checksum for project
[groupId=org.eclipse.jetty.ee10, artifactId=jetty-ee10-bom,
version=12.0.22-SNAPSHOT]
[INFO] Project inputs calculated in 0 ms. XXMM checksum [7b7b6120251dfd1d]
calculated in 0 ms.
[INFO] Attempting to restore project org.eclipse.jetty.ee10:jetty-ee10-bom
from build cache
[INFO] Local build found by checksum 7b7b6120251dfd1d
[INFO] Found cached build, restoring org.eclipse.jetty.ee10:jetty-ee10-bom
from cache by checksum 7b7b6120251dfd1d
[WARNING] Cached build doesn't contains all requested plugin executions
(missing:
[org.apache.maven.plugins:maven-resources-plugin:3.3.1:copy-resources
{execution: copy-resources},
org.apache.maven.plugins:maven-assembly-plugin:3.7.1:single {execution:
config-assembly}]), cannot restore
[INFO] Local build was not found by checksum 7b7b6120251dfd1d for
org.eclipse.jetty.ee10:jetty-ee10-bom
[INFO]
[INFO] --- spotless:2.44.4:check (default) @ jetty-ee10-bom ---
[INFO] Index file does not exist. Fallback to an empty index
[INFO] Sorting file /tmp/pom11239457262347372795.xml
[INFO] Pom file is already sorted, exiting
[INFO] Spotless.Pom is keeping 1 files clean - 0 needs changes to be clean,
1 were already clean, 0 were skipped because caching determined they were
already clean
[INFO]
[INFO] --- checkstyle:3.6.0:check (checkstyle-check) @ jetty-ee10-bom ---
[INFO] 开始检查……
检查完成。
[INFO] You have 0 Checkstyle violations.
[INFO]
[INFO] --- enforcer:3.5.0:enforce (ban-javax-servlet-api) @ jetty-ee10-bom
---
[INFO] Rule 0:
org.apache.maven.enforcer.rules.dependency.BannedDependencies passed
[INFO]
[INFO] --- enforcer:3.5.0:enforce (enforce-java) @ jetty-ee10-bom ---
[INFO] Rule 3:
org.eclipse.jetty.toolchain.enforcer.rules.RequireOsgiCompatibleVersionRule(versionOsgiRule)
passed
[INFO] Rule 4:
org.apache.maven.enforcer.rules.dependency.RequireUpperBoundDeps passed
[INFO]
[INFO] --- build-helper:3.6.0:parse-version (set-osgi-version) @
jetty-ee10-bom ---
[INFO]
[INFO] --- jacoco:0.8.13:prepare-agent (jacoco-initialize) @ jetty-ee10-bom
---
[INFO] argLine set to
-javaagent:/home/xenoamess/.m2/repository/org/jacoco/org.jacoco.agent/0.8.13/org.jacoco.agent-0.8.13-runtime.jar=destfile=/home/xenoamess/workspace/jetty.project/jetty-ee10/jetty-ee10-bom/target/jacoco.exec,excludes=**/org/eclipse/jetty/ant/**:*/org/eclipse/jetty/maven/its/**:**/org/eclipse/jetty/embedded/**:**/org/eclipse/jetty/asyncrest/**:**/org/eclipse/jetty/demo/**:**/org/eclipse/jetty/gcloud/**:**/org/eclipse/jetty/infinispan/**:**/org/eclipse/jetty/osgi/**:**/org/eclipse/jetty/spring/**:**/org/eclipse/jetty/http/spi/**:**/org/eclipse/jetty/tests/**:**/org/eclipse/jetty/test/**
[INFO]
[INFO] --- jacoco:0.8.13:prepare-agent (jacoco-setup-m-invoker-p) @
jetty-ee10-bom ---
[INFO] invoker.mavenOpts set to
-javaagent:/home/xenoamess/.m2/repository/org/jacoco/org.jacoco.agent/0.8.13/org.jacoco.agent-0.8.13-runtime.jar=destfile=/home/xenoamess/workspace/jetty.project/jetty-ee10/jetty-ee10-bom/target/jacoco.exec,excludes=**/org/eclipse/jetty/ant/**:*/org/eclipse/jetty/maven/its/**:**/org/eclipse/jetty/embedded/**:**/org/eclipse/jetty/asyncrest/**:**/org/eclipse/jetty/demo/**:**/org/eclipse/jetty/gcloud/**:**/org/eclipse/jetty/infinispan/**:**/org/eclipse/jetty/osgi/**:**/org/eclipse/jetty/spring/**:**/org/eclipse/jetty/http/spi/**:**/org/eclipse/jetty/tests/**:**/org/eclipse/jetty/test/**
[INFO]
[INFO] --- remote-resources:3.2.0:process (copy-shared-resources) @
jetty-ee10-bom ---
[INFO] Preparing remote bundle
org.eclipse.jetty:build-resources:12.0.22-SNAPSHOT
[INFO] Copying 0 resource from 1 bundle.
[INFO]
[INFO] --- jetty-version:2.7:attach-version-text (attach-version) @
jetty-ee10-bom ---
[INFO]
[INFO] --- resources:3.3.1:copy-resources (copy-resources) @ jetty-ee10-bom
---
[INFO] skip non existing resourceDirectory
/home/xenoamess/workspace/jetty.project/jetty-ee10/jetty-ee10-bom/src/main/config
[INFO]
[INFO] --- flatten:1.7.0:flatten (flatten) @ jetty-ee10-bom ---
[INFO] Generating flattened POM of project
org.eclipse.jetty.ee10:jetty-ee10-bom:pom:12.0.22-SNAPSHOT...
[INFO]
[INFO] --- bundle:5.1.9:manifest (default) @ jetty-ee10-bom ---
[WARNING] Ignoring project type pom - supportedProjectTypes = [jar,
maven-plugin]
[INFO]
[INFO] --- source:3.3.1:jar-no-fork (attach-sources) @ jetty-ee10-bom ---
[INFO]
[INFO] --- jacoco:0.8.13:report (jacoco-site) @ jetty-ee10-bom ---
[INFO] Skipping JaCoCo execution due to missing execution data file.
[INFO]
[INFO] --- assembly:3.7.1:single (config-assembly) @ jetty-ee10-bom ---
[INFO] Mimir session closed (RETRIEVED=0 CACHED=0)
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:3.7.1:single
(config-assembly) on project jetty-ee10-bom: Failed to create assembly:
Error creating assembly archive config: archive cannot be empty -> [Help 1]
[ERROR]
checked it did not invoke in mvn3 building log...
Sergey Chernov <se...@gmail.com> 于2025年5月29日周四 00:17写道：
> Hey, Delany. I will look into this.
> Also to avoid confusion let's continue this discussion in the proper thread
> as it's not related to maven 4 release
>
> On Wed, May 28, 2025 at 4:22 PM Delany <de...@gmail.com> wrote:
>
> > Hi Sergei,
> >
> > I'm running with this extension going forward. I don't use the build
> cache
> > (yet) so that's not an issue.
> > When trying to promote unit tests to a company that's resistant its
> helpful
> > to be able to say the tests won't slow down the build.
> >
> > We have one huge module though (project we're calling it now) with
> > extensive tests, and its a bottleneck for all that follow.
> > Typically we had to skip tests, but now we don't have to. Build time was
> > cut in half.
> >
> > I did notice jacoco coverage was disabled as I bound the
> > jacoco-maven-plugin report goal to the prepare-package phase.
> > As the documentation says, the phases have been switched around.
> > But can you make it work with the buildplan-maven-plugin:list-phases goal
> > so I can actually see which phases runs when, or is that up to this
> plugin
> > to figure out?
> >
> > Kind regards,
> > Delany
> >
> >
> > On Wed, 28 May 2025 at 14:55, Sergey Chernov <se...@gmail.com>
> > wrote:
> >
> > > Guillaume, that's awesome. It's good that there is no rush with it.
> > > Once I'll have insights, I'll share them.
> > >
> > > Xeno, the project I'm checking is private unfortunately. Also this can
> be
> > > quite challenging to find a good Maven multi-module project as a
> > reference
> > > for performance testing and compatibility validations, as many of big
> > > projects e.g. have flaky tests and other issues.
> > > Some of the biggest that I've seen:
> > > * https://github.com/quarkusio/quarkus (has lots of customizations in
> > > .mvn/extensions.xml)
> > > * https://github.com/apache/dubbo
> > > * https://github.com/apache/hadoop
> > > * https://github.com/apache/struts
> > > * https://github.com/vaadin/flow and
> https://github.com/vaadin/framework
> > >
> > >
> > > On Wed, May 28, 2025 at 2:16 PM Guillaume Nodet <gn...@apache.org>
> > wrote:
> > >
> > > > After considering the concerns about API stability, plugin
> > > > compatibility, and the performance issues reported by Sergey (4x
> > > > slower in rc3), I agree with Sylwester, Benjamin, and Elliotte that
> we
> > > > should opt for an rc4 to address these issues. My proposal is to
> > > > release a final release candidate (rc4) soon, aiming for a General
> > > > Availability (GA) release in September. Post rc4, I suggest creating
> a
> > > > 4.0.x branch to start work on 4.1.0. For 4.1.0, we could introduce
> API
> > > > changes like records and sequenced collections, as well as new
> > > > features such as mixins, cascading profiles, server aliases, JDK 21
> > > > (still under discussion) and more....
> > > >
> > > > The recent API changes for JPMS, as Martin noted, only affect the
> > > > experimental API, so they shouldn’t block the release. On Matthias’s
> > > > suggestion, enabling GitHub Issues across all repositories before the
> > > > GA seems like a good idea to improve user feedback. Let’s focus on
> > > > stabilizing rc4 and addressing performance bottlenecks, possibly
> > > > exploring Martin’s O(N²) concerns with profiling, as Sergey offered.
> > > >
> > > > What do you think about this plan?
> > > >
> > > > On a side note, I created a few months ago a project to check Maven 4
> > > > compatibility with all Apache projects using Maven. The results for
> > > > RC-3 can be found at
> > > > https://github.com/gnodet/maven4-testing/issues/2812. Most of the
> > > > errors are caused by the use of incompatible plugins (which needs to
> > > > be updated) or incorrect POMs (as Maven 4 is more strict about a few
> > > > things). What would be nice is a tool to integrate in the shell that
> > > > would fix those known incompatibilities, so that users would have an
> > > > easier migration path. And we could apply it to this project to make
> > > > more green boxes.
> > > >
> > > > Le mer. 21 mai 2025 à 08:11, Guillaume Nodet <gn...@apache.org> a
> > > écrit :
> > > > >
> > > > > Hey Maven Devs,
> > > > >
> > > > > We're gearing up to release a new version from the master branch.
> I'm
> > > > thinking we should go for 4.0.0 instead of rc-4. What do you all
> think?
> > > Any
> > > > feedback or ideas on the versioning or release plan? Let’s hear it!
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Guillaume
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > ------------------------
> > > > Guillaume Nodet
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> >
>
Re: Maven 4.0.0 Release - Thoughts?
Posted by Sergey Chernov <se...@gmail.com>.
Hey, Delany. I will look into this.
Also to avoid confusion let's continue this discussion in the proper thread
as it's not related to maven 4 release
On Wed, May 28, 2025 at 4:22 PM Delany <de...@gmail.com> wrote:
> Hi Sergei,
>
> I'm running with this extension going forward. I don't use the build cache
> (yet) so that's not an issue.
> When trying to promote unit tests to a company that's resistant its helpful
> to be able to say the tests won't slow down the build.
>
> We have one huge module though (project we're calling it now) with
> extensive tests, and its a bottleneck for all that follow.
> Typically we had to skip tests, but now we don't have to. Build time was
> cut in half.
>
> I did notice jacoco coverage was disabled as I bound the
> jacoco-maven-plugin report goal to the prepare-package phase.
> As the documentation says, the phases have been switched around.
> But can you make it work with the buildplan-maven-plugin:list-phases goal
> so I can actually see which phases runs when, or is that up to this plugin
> to figure out?
>
> Kind regards,
> Delany
>
>
> On Wed, 28 May 2025 at 14:55, Sergey Chernov <se...@gmail.com>
> wrote:
>
> > Guillaume, that's awesome. It's good that there is no rush with it.
> > Once I'll have insights, I'll share them.
> >
> > Xeno, the project I'm checking is private unfortunately. Also this can be
> > quite challenging to find a good Maven multi-module project as a
> reference
> > for performance testing and compatibility validations, as many of big
> > projects e.g. have flaky tests and other issues.
> > Some of the biggest that I've seen:
> > * https://github.com/quarkusio/quarkus (has lots of customizations in
> > .mvn/extensions.xml)
> > * https://github.com/apache/dubbo
> > * https://github.com/apache/hadoop
> > * https://github.com/apache/struts
> > * https://github.com/vaadin/flow and https://github.com/vaadin/framework
> >
> >
> > On Wed, May 28, 2025 at 2:16 PM Guillaume Nodet <gn...@apache.org>
> wrote:
> >
> > > After considering the concerns about API stability, plugin
> > > compatibility, and the performance issues reported by Sergey (4x
> > > slower in rc3), I agree with Sylwester, Benjamin, and Elliotte that we
> > > should opt for an rc4 to address these issues. My proposal is to
> > > release a final release candidate (rc4) soon, aiming for a General
> > > Availability (GA) release in September. Post rc4, I suggest creating a
> > > 4.0.x branch to start work on 4.1.0. For 4.1.0, we could introduce API
> > > changes like records and sequenced collections, as well as new
> > > features such as mixins, cascading profiles, server aliases, JDK 21
> > > (still under discussion) and more....
> > >
> > > The recent API changes for JPMS, as Martin noted, only affect the
> > > experimental API, so they shouldn’t block the release. On Matthias’s
> > > suggestion, enabling GitHub Issues across all repositories before the
> > > GA seems like a good idea to improve user feedback. Let’s focus on
> > > stabilizing rc4 and addressing performance bottlenecks, possibly
> > > exploring Martin’s O(N²) concerns with profiling, as Sergey offered.
> > >
> > > What do you think about this plan?
> > >
> > > On a side note, I created a few months ago a project to check Maven 4
> > > compatibility with all Apache projects using Maven. The results for
> > > RC-3 can be found at
> > > https://github.com/gnodet/maven4-testing/issues/2812. Most of the
> > > errors are caused by the use of incompatible plugins (which needs to
> > > be updated) or incorrect POMs (as Maven 4 is more strict about a few
> > > things). What would be nice is a tool to integrate in the shell that
> > > would fix those known incompatibilities, so that users would have an
> > > easier migration path. And we could apply it to this project to make
> > > more green boxes.
> > >
> > > Le mer. 21 mai 2025 à 08:11, Guillaume Nodet <gn...@apache.org> a
> > écrit :
> > > >
> > > > Hey Maven Devs,
> > > >
> > > > We're gearing up to release a new version from the master branch. I'm
> > > thinking we should go for 4.0.0 instead of rc-4. What do you all think?
> > Any
> > > feedback or ideas on the versioning or release plan? Let’s hear it!
> > > >
> > > > Cheers,
> > > >
> > > > Guillaume
> > > >
> > > >
> > >
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
>
Re: Maven 4.0.0 Release - Thoughts?
Posted by Delany <de...@gmail.com>.
Hi Sergei,
I'm running with this extension going forward. I don't use the build cache
(yet) so that's not an issue.
When trying to promote unit tests to a company that's resistant its helpful
to be able to say the tests won't slow down the build.
We have one huge module though (project we're calling it now) with
extensive tests, and its a bottleneck for all that follow.
Typically we had to skip tests, but now we don't have to. Build time was
cut in half.
I did notice jacoco coverage was disabled as I bound the
jacoco-maven-plugin report goal to the prepare-package phase.
As the documentation says, the phases have been switched around.
But can you make it work with the buildplan-maven-plugin:list-phases goal
so I can actually see which phases runs when, or is that up to this plugin
to figure out?
Kind regards,
Delany
On Wed, 28 May 2025 at 14:55, Sergey Chernov <se...@gmail.com> wrote:
> Guillaume, that's awesome. It's good that there is no rush with it.
> Once I'll have insights, I'll share them.
>
> Xeno, the project I'm checking is private unfortunately. Also this can be
> quite challenging to find a good Maven multi-module project as a reference
> for performance testing and compatibility validations, as many of big
> projects e.g. have flaky tests and other issues.
> Some of the biggest that I've seen:
> * https://github.com/quarkusio/quarkus (has lots of customizations in
> .mvn/extensions.xml)
> * https://github.com/apache/dubbo
> * https://github.com/apache/hadoop
> * https://github.com/apache/struts
> * https://github.com/vaadin/flow and https://github.com/vaadin/framework
>
>
> On Wed, May 28, 2025 at 2:16 PM Guillaume Nodet <gn...@apache.org> wrote:
>
> > After considering the concerns about API stability, plugin
> > compatibility, and the performance issues reported by Sergey (4x
> > slower in rc3), I agree with Sylwester, Benjamin, and Elliotte that we
> > should opt for an rc4 to address these issues. My proposal is to
> > release a final release candidate (rc4) soon, aiming for a General
> > Availability (GA) release in September. Post rc4, I suggest creating a
> > 4.0.x branch to start work on 4.1.0. For 4.1.0, we could introduce API
> > changes like records and sequenced collections, as well as new
> > features such as mixins, cascading profiles, server aliases, JDK 21
> > (still under discussion) and more....
> >
> > The recent API changes for JPMS, as Martin noted, only affect the
> > experimental API, so they shouldn’t block the release. On Matthias’s
> > suggestion, enabling GitHub Issues across all repositories before the
> > GA seems like a good idea to improve user feedback. Let’s focus on
> > stabilizing rc4 and addressing performance bottlenecks, possibly
> > exploring Martin’s O(N²) concerns with profiling, as Sergey offered.
> >
> > What do you think about this plan?
> >
> > On a side note, I created a few months ago a project to check Maven 4
> > compatibility with all Apache projects using Maven. The results for
> > RC-3 can be found at
> > https://github.com/gnodet/maven4-testing/issues/2812. Most of the
> > errors are caused by the use of incompatible plugins (which needs to
> > be updated) or incorrect POMs (as Maven 4 is more strict about a few
> > things). What would be nice is a tool to integrate in the shell that
> > would fix those known incompatibilities, so that users would have an
> > easier migration path. And we could apply it to this project to make
> > more green boxes.
> >
> > Le mer. 21 mai 2025 à 08:11, Guillaume Nodet <gn...@apache.org> a
> écrit :
> > >
> > > Hey Maven Devs,
> > >
> > > We're gearing up to release a new version from the master branch. I'm
> > thinking we should go for 4.0.0 instead of rc-4. What do you all think?
> Any
> > feedback or ideas on the versioning or release plan? Let’s hear it!
> > >
> > > Cheers,
> > >
> > > Guillaume
> > >
> > >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Maven 4.0.0 Release - Thoughts?
Posted by Xeno Amess <xe...@gmail.com>.
I tested log4j2 an hour ago. on my computer mvn3 use 2:00(min), mvn4 use
1:53(min)
no much difference.
would try test your examples later.
Sergey Chernov <se...@gmail.com> 于2025年5月28日周三 20:55写道：
> Guillaume, that's awesome. It's good that there is no rush with it.
> Once I'll have insights, I'll share them.
>
> Xeno, the project I'm checking is private unfortunately. Also this can be
> quite challenging to find a good Maven multi-module project as a reference
> for performance testing and compatibility validations, as many of big
> projects e.g. have flaky tests and other issues.
> Some of the biggest that I've seen:
> * https://github.com/quarkusio/quarkus (has lots of customizations in
> .mvn/extensions.xml)
> * https://github.com/apache/dubbo
> * https://github.com/apache/hadoop
> * https://github.com/apache/struts
> * https://github.com/vaadin/flow and https://github.com/vaadin/framework
>
>
> On Wed, May 28, 2025 at 2:16 PM Guillaume Nodet <gn...@apache.org> wrote:
>
> > After considering the concerns about API stability, plugin
> > compatibility, and the performance issues reported by Sergey (4x
> > slower in rc3), I agree with Sylwester, Benjamin, and Elliotte that we
> > should opt for an rc4 to address these issues. My proposal is to
> > release a final release candidate (rc4) soon, aiming for a General
> > Availability (GA) release in September. Post rc4, I suggest creating a
> > 4.0.x branch to start work on 4.1.0. For 4.1.0, we could introduce API
> > changes like records and sequenced collections, as well as new
> > features such as mixins, cascading profiles, server aliases, JDK 21
> > (still under discussion) and more....
> >
> > The recent API changes for JPMS, as Martin noted, only affect the
> > experimental API, so they shouldn’t block the release. On Matthias’s
> > suggestion, enabling GitHub Issues across all repositories before the
> > GA seems like a good idea to improve user feedback. Let’s focus on
> > stabilizing rc4 and addressing performance bottlenecks, possibly
> > exploring Martin’s O(N²) concerns with profiling, as Sergey offered.
> >
> > What do you think about this plan?
> >
> > On a side note, I created a few months ago a project to check Maven 4
> > compatibility with all Apache projects using Maven. The results for
> > RC-3 can be found at
> > https://github.com/gnodet/maven4-testing/issues/2812. Most of the
> > errors are caused by the use of incompatible plugins (which needs to
> > be updated) or incorrect POMs (as Maven 4 is more strict about a few
> > things). What would be nice is a tool to integrate in the shell that
> > would fix those known incompatibilities, so that users would have an
> > easier migration path. And we could apply it to this project to make
> > more green boxes.
> >
> > Le mer. 21 mai 2025 à 08:11, Guillaume Nodet <gn...@apache.org> a
> écrit :
> > >
> > > Hey Maven Devs,
> > >
> > > We're gearing up to release a new version from the master branch. I'm
> > thinking we should go for 4.0.0 instead of rc-4. What do you all think?
> Any
> > feedback or ideas on the versioning or release plan? Let’s hear it!
> > >
> > > Cheers,
> > >
> > > Guillaume
> > >
> > >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Maven 4.0.0 Release - Thoughts?
Posted by Sergey Chernov <se...@gmail.com>.
Guillaume, that's awesome. It's good that there is no rush with it.
Once I'll have insights, I'll share them.
Xeno, the project I'm checking is private unfortunately. Also this can be
quite challenging to find a good Maven multi-module project as a reference
for performance testing and compatibility validations, as many of big
projects e.g. have flaky tests and other issues.
Some of the biggest that I've seen:
* https://github.com/quarkusio/quarkus (has lots of customizations in
.mvn/extensions.xml)
* https://github.com/apache/dubbo
* https://github.com/apache/hadoop
* https://github.com/apache/struts
* https://github.com/vaadin/flow and https://github.com/vaadin/framework
On Wed, May 28, 2025 at 2:16 PM Guillaume Nodet <gn...@apache.org> wrote:
> After considering the concerns about API stability, plugin
> compatibility, and the performance issues reported by Sergey (4x
> slower in rc3), I agree with Sylwester, Benjamin, and Elliotte that we
> should opt for an rc4 to address these issues. My proposal is to
> release a final release candidate (rc4) soon, aiming for a General
> Availability (GA) release in September. Post rc4, I suggest creating a
> 4.0.x branch to start work on 4.1.0. For 4.1.0, we could introduce API
> changes like records and sequenced collections, as well as new
> features such as mixins, cascading profiles, server aliases, JDK 21
> (still under discussion) and more....
>
> The recent API changes for JPMS, as Martin noted, only affect the
> experimental API, so they shouldn’t block the release. On Matthias’s
> suggestion, enabling GitHub Issues across all repositories before the
> GA seems like a good idea to improve user feedback. Let’s focus on
> stabilizing rc4 and addressing performance bottlenecks, possibly
> exploring Martin’s O(N²) concerns with profiling, as Sergey offered.
>
> What do you think about this plan?
>
> On a side note, I created a few months ago a project to check Maven 4
> compatibility with all Apache projects using Maven. The results for
> RC-3 can be found at
> https://github.com/gnodet/maven4-testing/issues/2812. Most of the
> errors are caused by the use of incompatible plugins (which needs to
> be updated) or incorrect POMs (as Maven 4 is more strict about a few
> things). What would be nice is a tool to integrate in the shell that
> would fix those known incompatibilities, so that users would have an
> easier migration path. And we could apply it to this project to make
> more green boxes.
>
> Le mer. 21 mai 2025 à 08:11, Guillaume Nodet <gn...@apache.org> a écrit :
> >
> > Hey Maven Devs,
> >
> > We're gearing up to release a new version from the master branch. I'm
> thinking we should go for 4.0.0 instead of rc-4. What do you all think? Any
> feedback or ideas on the versioning or release plan? Let’s hear it!
> >
> > Cheers,
> >
> > Guillaume
> >
> >
>
>
> --
> ------------------------
> Guillaume Nodet
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Maven 4.0.0 Release - Thoughts?
Posted by Guillaume Nodet <gn...@apache.org>.
After considering the concerns about API stability, plugin
compatibility, and the performance issues reported by Sergey (4x
slower in rc3), I agree with Sylwester, Benjamin, and Elliotte that we
should opt for an rc4 to address these issues. My proposal is to
release a final release candidate (rc4) soon, aiming for a General
Availability (GA) release in September. Post rc4, I suggest creating a
4.0.x branch to start work on 4.1.0. For 4.1.0, we could introduce API
changes like records and sequenced collections, as well as new
features such as mixins, cascading profiles, server aliases, JDK 21
(still under discussion) and more....
The recent API changes for JPMS, as Martin noted, only affect the
experimental API, so they shouldn’t block the release. On Matthias’s
suggestion, enabling GitHub Issues across all repositories before the
GA seems like a good idea to improve user feedback. Let’s focus on
stabilizing rc4 and addressing performance bottlenecks, possibly
exploring Martin’s O(N²) concerns with profiling, as Sergey offered.
What do you think about this plan?
On a side note, I created a few months ago a project to check Maven 4
compatibility with all Apache projects using Maven. The results for
RC-3 can be found at
https://github.com/gnodet/maven4-testing/issues/2812. Most of the
errors are caused by the use of incompatible plugins (which needs to
be updated) or incorrect POMs (as Maven 4 is more strict about a few
things). What would be nice is a tool to integrate in the shell that
would fix those known incompatibilities, so that users would have an
easier migration path. And we could apply it to this project to make
more green boxes.
Le mer. 21 mai 2025 à 08:11, Guillaume Nodet <gn...@apache.org> a écrit :
>
> Hey Maven Devs,
>
> We're gearing up to release a new version from the master branch. I'm thinking we should go for 4.0.0 instead of rc-4. What do you all think? Any feedback or ideas on the versioning or release plan? Let’s hear it!
>
> Cheers,
>
> Guillaume
>
>
--
------------------------
Guillaume Nodet
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0 Release - Thoughts?
Posted by Slawomir Jaranowski <s....@gmail.com>.
On Thu, 22 May 2025 at 09:24, Hervé Boutemy <hb...@apache.org> wrote:
> yes to try to make sure Maven 4.0.0 will run smoothly on Java 24
>
> on tying Maven 4.0.0 release to Jira to GH Issues migration: is there a
> strong
> reason for coupling these 2 huge beasts?
>
>
> longer analysis:
>
> Jira to GH Issues migration has started everywhere (66 as of now, if
> tracking
> is accurate [1]), but near nothing is finished
>
First step - switch to GitHub was done in many projects
>
> concretely: how many releases of simple plugins or components have been
> done
> with GH Issues and associated release notes prepared by the new approach?
> and
> what if I add "by people other than Slawek"?
> hint: [2]
>
Another question: how many releases do we have at all?
And yes if something in a new way is not clear we need to work on it.
> We have so many small plugins or components to get experience. I expected
> that
> by mid-may we would have huge experience with the new approach: that's not
> the
> case
>
> Maven core is the biggest, most complex, migration we have: I'd be
> seriously
> worried if we couple the Maven 4.0.0 release with Jira to GH Issues
> migration
>
> Regards,
>
> Hervé
>
>
> [1] https://cwiki.apache.org/confluence/display/MAVEN/
> JIRA+to+GitHub+Issues+switching
>
> [2]
> https://lists.apache.org/list?dev@maven.apache.org:lte=1M:[VOTE]%20Release
>
> Le mercredi 21 mai 2025, 22:03:06 CEST Matthias Bünger a écrit :
> > Hey,
> > I‘ve lost the overview to the java 24 issues, but if I got it right the
> sisu
> > 0.94 can handle it. So if we are fine on running on java 24 and our 4.x
> > plugins (there are some in beta etc, look at the update parent to 44 of
> > source-p for example) are final too, I think we are good to go. Why the
> > plugins? Think it’s not good to say „here main is final, use the 4.x
> > plugins of those exist, bit yes they are alpha/beta“.
> >
> > Another point we can consider: finish enable github issues for all
> relevant
> > projects to make it easier and consisten for users to provide
> > feedback/issues. Slawek and I are close to finish. If I have it in mind
> > correctly about 15 repos left, including maven itself (long standing
> draft
> > afair).
> >
> > Have a good night everyone.
> > Matthias
> >
> > Sent from mobile
> >
> > > Am 21.05.2025 um 08:12 schrieb Guillaume Nodet <gn...@apache.org>:
> > >
> > > Hey Maven Devs,
> > >
> > > We're gearing up to release a new version from the master branch. I'm
> > > thinking we should go for 4.0.0 instead of rc-4. What do you all think?
> > > Any
> > > feedback or ideas on the versioning or release plan? Let’s hear it!
> > >
> > > Cheers,
> > >
> > > Guillaume
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Sławomir Jaranowski
Re: Maven 4.0.0 Release - Thoughts?
Posted by Hervé Boutemy <hb...@apache.org>.
Le jeudi 22 mai 2025, 17:30:20 CEST Matthias Bünger a écrit :
> Am 22.05.2025 um 09:23 schrieb Hervé Boutemy:
> > yes to try to make sure Maven 4.0.0 will run smoothly on Java 24
> >
> > on tying Maven 4.0.0 release to Jira to GH Issues migration: is there a
> > strong reason for coupling these 2 huge beasts?
>
> Hi Hervè,
>
> TLDR: No strong reason ;)
>
> Long version: Maybe I was not clear with my suggestion. I don't want to
> coupling the full migration including moving JIRA issues to Github, but
> to discuss if we want to finish to enable github issues on all
> repositories, so people can more easy report issues to us (which was one
> of the pros in the discussion to use GH issues) as I personally believe
> that, when Maven 4 is out, there will be more users who want to provide.
so finally there is a (not so bad) reason: anticipating feedback when Maven 4
is out (with the complexity of creating a Jira accounts = why we started the
move)
>
> Current stand (if I not miscounted) 21 repositores are left to ENABLE
> issues. I will work on further at the weekend so I think we will be done
> soon with that. Migration of existing JIRA is another story, which comes
> after that but which is not part of my suggestion.
it seems the only answer is "let's go faster": I won't fight, it seems I'm
alone, and the target is necessary
I'll try to do a release of something, and I'll see if I'm over cautious.
On activating on Maven core (and blocking new issues on Jira), I'll let the
big committers on it decide
>
> Greetings
>
> Matthias
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0 Release - Thoughts?
Posted by Matthias Bünger <mb...@apache.org>.
Am 22.05.2025 um 09:23 schrieb Hervé Boutemy:
> yes to try to make sure Maven 4.0.0 will run smoothly on Java 24
>
> on tying Maven 4.0.0 release to Jira to GH Issues migration: is there a strong
> reason for coupling these 2 huge beasts?
Hi Hervè,
TLDR: No strong reason ;)
Long version: Maybe I was not clear with my suggestion. I don't want to
coupling the full migration including moving JIRA issues to Github, but
to discuss if we want to finish to enable github issues on all
repositories, so people can more easy report issues to us (which was one
of the pros in the discussion to use GH issues) as I personally believe
that, when Maven 4 is out, there will be more users who want to provide.
Current stand (if I not miscounted) 21 repositores are left to ENABLE
issues. I will work on further at the weekend so I think we will be done
soon with that. Migration of existing JIRA is another story, which comes
after that but which is not part of my suggestion.
Greetings
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0 Release - Thoughts?
Posted by Hervé Boutemy <hb...@apache.org>.
yes to try to make sure Maven 4.0.0 will run smoothly on Java 24
on tying Maven 4.0.0 release to Jira to GH Issues migration: is there a strong
reason for coupling these 2 huge beasts?
longer analysis:
Jira to GH Issues migration has started everywhere (66 as of now, if tracking
is accurate [1]), but near nothing is finished
concretely: how many releases of simple plugins or components have been done
with GH Issues and associated release notes prepared by the new approach? and
what if I add "by people other than Slawek"?
hint: [2]
We have so many small plugins or components to get experience. I expected that
by mid-may we would have huge experience with the new approach: that's not the
case
Maven core is the biggest, most complex, migration we have: I'd be seriously
worried if we couple the Maven 4.0.0 release with Jira to GH Issues migration
Regards,
Hervé
[1] https://cwiki.apache.org/confluence/display/MAVEN/
JIRA+to+GitHub+Issues+switching
[2] https://lists.apache.org/list?dev@maven.apache.org:lte=1M:[VOTE]%20Release
Le mercredi 21 mai 2025, 22:03:06 CEST Matthias Bünger a écrit :
> Hey,
> I‘ve lost the overview to the java 24 issues, but if I got it right the sisu
> 0.94 can handle it. So if we are fine on running on java 24 and our 4.x
> plugins (there are some in beta etc, look at the update parent to 44 of
> source-p for example) are final too, I think we are good to go. Why the
> plugins? Think it’s not good to say „here main is final, use the 4.x
> plugins of those exist, bit yes they are alpha/beta“.
>
> Another point we can consider: finish enable github issues for all relevant
> projects to make it easier and consisten for users to provide
> feedback/issues. Slawek and I are close to finish. If I have it in mind
> correctly about 15 repos left, including maven itself (long standing draft
> afair).
>
> Have a good night everyone.
> Matthias
>
> Sent from mobile
>
> > Am 21.05.2025 um 08:12 schrieb Guillaume Nodet <gn...@apache.org>:
> >
> > Hey Maven Devs,
> >
> > We're gearing up to release a new version from the master branch. I'm
> > thinking we should go for 4.0.0 instead of rc-4. What do you all think?
> > Any
> > feedback or ideas on the versioning or release plan? Let’s hear it!
> >
> > Cheers,
> >
> > Guillaume
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0 Release - Thoughts?
Posted by Matthias Bünger <ru...@web.de.INVALID>.
Hey,
I‘ve lost the overview to the java 24 issues, but if I got it right the sisu 0.94 can handle it. So if we are fine on running on java 24 and our 4.x plugins (there are some in beta etc, look at the update parent to 44 of source-p for example) are final too, I think we are good to go.
Why the plugins? Think it’s not good to say „here main is final, use the 4.x plugins of those exist, bit yes they are alpha/beta“.
Another point we can consider: finish enable github issues for all relevant projects to make it easier and consisten for users to provide feedback/issues. Slawek and I are close to finish. If I have it in mind correctly about 15 repos left, including maven itself (long standing draft afair).
Have a good night everyone.
Matthias
Sent from mobile
> Am 21.05.2025 um 08:12 schrieb Guillaume Nodet <gn...@apache.org>:
>
> Hey Maven Devs,
>
> We're gearing up to release a new version from the master branch. I'm
> thinking we should go for 4.0.0 instead of rc-4. What do you all think? Any
> feedback or ideas on the versioning or release plan? Let’s hear it!
>
> Cheers,
>
> Guillaume
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven 4.0.0 Release - Thoughts?
Posted by Olivier Lamy <ol...@apache.org>.
Sounds like a good plan!
On Wed, 21 May 2025 at 4:12 pm, Guillaume Nodet <gn...@apache.org> wrote:
> Hey Maven Devs,
>
> We're gearing up to release a new version from the master branch. I'm
> thinking we should go for 4.0.0 instead of rc-4. What do you all think? Any
> feedback or ideas on the versioning or release plan? Let’s hear it!
>
> Cheers,
>
> Guillaume
>