Re: [Discussion] What needs to be done for 4.0.0 GA?

2026-02-22 Thread Matthias Bünger 

Hi all,
thank you all for the responses. I added missing To-Dos from the mailing 
list to the wiki page [1]. After that I tried to group points by topic.


As a conclusion, I identified the following topics we work is needed for 
4.0.0.


1. Blocking issues ("bugs")
2. Maven 4 API
3. Maven 4 Namespace
4. Compatibility of 3rd party tools and infrastructure services
5. Compatibility of 3rd party "library projects"

I personally see a gap between the first three and the last two, as the 
last two depend on the state/decisions of the first three (esp. 2+3). I 
suggest to decide on them in either Maarten's discussion thread [2] or a 
vote or somehow else. So please head over to the discussion thread and 
keep this thread here clean for responses of new things poping up or 
change state of existing things.


Matthias

P.S. I won't be active very much in March, but will try to keep an eye 
on this thread.


[1] 
https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0+GA+checklist

[2] https://lists.apache.org/thread/f012nxx8msltcp06f2h848n1rkowl4kj


Am 12.02.2026 um 18:10 schrieb Matthias Bünger:

Good evening everybody,
last week a small number of commiter and PMC had a chat about the 
current situation about Maven 4.0.0.
Nobody of the people attended was aware of any outstanding blocking 
issues, but also nobody could precicle say what else needs to be done 
for a GA release. As a result we collected some points on a wiki page 
[1].


Today Benjamin asked me to send a mail to the list, to gather 
feedback, if we missed anything . Do you agree with the points on the 
list or do you see any (and if yes, which) blocker that needs to be 
done, before we can consider a 4.0.0 GA?


Please note: This discussion should focus on "What's need to be done 
for 4.0.0". It's not about discussions about will there new RC or was 
RC5 the last RC. This can be discussed when we have a complete (as 
possible) list of TO-DO's. So please avoid to restart any discussion 
about alpha/beta/RC versions in this thread. What happend, happend 
(including new features, like Maven Update tool, during RC phase) - 
thank you.


Matthias

[1]: 
https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0+GA+checklist



-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]



-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Re: [Discussion] What needs to be done for 4.0.0 GA?

2026-02-14 Thread Romain Manni-Bucau 
Le sam. 14 févr. 2026 à 22:56, Martin Desruisseaux <
[email protected]> a écrit :

> Le 14/02/2026 à 21:19, Romain Manni-Bucau a écrit :
>
> > Side note: while maven 5 itself could use JPMS for its api + core +
> > resolver modules (and likely nothing else), the rest must not use JPMS
> > by design and stay user friendly (extensions + plugins)
>
> It is a little bit off-topic, but just for information: I hope to
> propose a full modularisation of Maven 5, including core and all
> plugins. I have see in the past arguments saying that we cannot discover
> plugins at runtime using JPMS. But this not true: it is just that the
> way to do that is different (we need to use java.lang.ModuleLayer).
>

This is not the blocker, this part is easy, the blocker is that a lot of
mojo will never embrace JPMS so we must run without JPMS at all extensions
and plugins (doesnt mean we can't run a JPMS plugin, OSGi does it for ex,
but means this must not be a requirement).


>
> Anyway, this is probably not a topic before a few years.
>
>  Martin
>
>

Re: [Discussion] What needs to be done for 4.0.0 GA?

2026-02-14 Thread Martin Desruisseaux via dev 

Le 14/02/2026 à 21:19, Romain Manni-Bucau a écrit :

Side note: while maven 5 itself could use JPMS for its api + core + 
resolver modules (and likely nothing else), the rest must not use JPMS 
by design and stay user friendly (extensions + plugins)


It is a little bit off-topic, but just for information: I hope to 
propose a full modularisation of Maven 5, including core and all 
plugins. I have see in the past arguments saying that we cannot discover 
plugins at runtime using JPMS. But this not true: it is just that the 
way to do that is different (we need to use java.lang.ModuleLayer).


Anyway, this is probably not a topic before a few years.

    Martin



-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Re: [Discussion] What needs to be done for 4.0.0 GA?

2026-02-14 Thread Romain Manni-Bucau 
Well my view is that maven 3 was 100% wrong since it didn't have any API
and lived years, it did break API and people survived.
That you are used to old style API which will be totally inconsistent with
the IoC (static utilities) or modern over engineered design it is mainly a
habit thing and I our community is wide enough to be sure to not converge
there.
So overall if the API works and being said we are always free to keep
adding new API, potentially simpler services (please never anything static,
it is too bothersome to override/extends and shouts ourselves in the feet
in terms of design).
So long story short, no block.

Side note: while maven 5 itself could use JPMS for its api + core +
resolver modules (and likely nothing else), the rest must not use JPMS by
design and stay user friendly (extensions + plugins) so JPMS can be a bad
bet for a redesign but it doesn't change the fact services design is better
than in maven 3 and can be enhanced without any breaking change.

=> all good to release on that aspect

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

Javaccino founder (Java/.NET service - contact via linkedin)


Le sam. 14 févr. 2026 à 11:10, Martin Desruisseaux via dev <
[email protected]> a écrit :

> Hello all
>
> I also question whether the public API really needs so many services and
> interfaces. But I think that a compatibility break in Maven 5 may be
> unavoidable anyway, even if we didn't introduced any new API in Maven 4
> compared to Maven 3. One reason is because in my understanding, the
> classes in the `org.eclipse.aether` packages are practically public API.
> But those classes duplicate Maven classes: a `Dependency` class exists
> in Aether packages, in Maven API, in Maven model, and more. Debugging
> Maven is tedious: an Aether Dependency is wrapped in a Maven Dependency,
> then unwrapped when we need to invoke an Aether API, then wrapped again,
> etc. Consequently, following step-by-step in a debugger is confusing. We
> could improve by merging the Aether classes with Maven implementation
> classes, but it would break compatibility for plugins that use the
> Aether classes. Said otherwise, we inherited from Maven 3 a technical
> debt that cannot be resolved (in my understanding) without compatibility
> break. Maven 4 is not breaking that compatibility yet, but we may
> consider whether Maven 5 should break it.
>
> That said, I do have some concerns about Maven 4 API:
>
>   * I share with Elliotte the impression that we have gone a little bit
> too far in separating everything in interfaces.
>   * I think that the implementations have too many public classes. I
> think that it would have been safer to keep all implementations
> private or package-private by default, and change to protected or
> public access only when it appears to be needed.
>   * We didn't anticipated records in the names of the methods declared
> in interfaces. This is unfortunate since records could simplify a
> lot all the places where Maven uses the "for = foo.withBar(bar)"
> pattern, and probably improves performance as well.
>
> Maven 4 wasn't designed with records from the ground because the upgrade
> from Java 8 to Java 17 came too late in Maven 4 history (most of Maven
> API was already in place when the upgrade was done). However, even if we
> anticipated records, we would be forced to implement the "for =
> foo.withBar(bar)" pattern anyway because we cannot use JEP 468 (Derived
> Record Creation) yet. Removing that pattern in Maven 5 (if we choose to
> do so) would be another compatibility break.
>
> Finally, after completion of the work in Maven 4 for better support of
> Java modules, I hope to propose a modularisation of Maven 5 itself.
> Again it may bring simplifications such as removing the need for
> plexus-classworlds. But it may be another source of incompatibility.
>
> In summary, while I agree that there are issues with Maven 4 API, those
> issues may be nuanced in the perspective of an hardly avoidable
> compatibility break in (maybe) Maven 5 anyway.
>
>  Martin
>
>
> Le 13/02/2026 à 16:53, Elliotte Rusty Harold a écrit :
> > IMHO Maven 4.0 is not close to ready for release. The most serious
> > issue is the change of namespace. That's a major mistake that will
> > cause large problems for developers, especially those who use tools
> > other than Maven itself.
> >
> > Second most serious issue is finalization of APIs. @Experimental
> > features need to be committed to or removed.
> >
> > Similarly APIs have been deprecated but not documented with
> > replacement. That also needs to be finished.
> >
> > Finally  much of the new API is

Re: [Discussion] What needs to be done for 4.0.0 GA?

2026-02-14 Thread Martin Desruisseaux via dev 

Hello all

I also question whether the public API really needs so many services and 
interfaces. But I think that a compatibility break in Maven 5 may be 
unavoidable anyway, even if we didn't introduced any new API in Maven 4 
compared to Maven 3. One reason is because in my understanding, the 
classes in the `org.eclipse.aether` packages are practically public API. 
But those classes duplicate Maven classes: a `Dependency` class exists 
in Aether packages, in Maven API, in Maven model, and more. Debugging 
Maven is tedious: an Aether Dependency is wrapped in a Maven Dependency, 
then unwrapped when we need to invoke an Aether API, then wrapped again, 
etc. Consequently, following step-by-step in a debugger is confusing. We 
could improve by merging the Aether classes with Maven implementation 
classes, but it would break compatibility for plugins that use the 
Aether classes. Said otherwise, we inherited from Maven 3 a technical 
debt that cannot be resolved (in my understanding) without compatibility 
break. Maven 4 is not breaking that compatibility yet, but we may 
consider whether Maven 5 should break it.


That said, I do have some concerns about Maven 4 API:

 * I share with Elliotte the impression that we have gone a little bit
   too far in separating everything in interfaces.
 * I think that the implementations have too many public classes. I
   think that it would have been safer to keep all implementations
   private or package-private by default, and change to protected or
   public access only when it appears to be needed.
 * We didn't anticipated records in the names of the methods declared
   in interfaces. This is unfortunate since records could simplify a
   lot all the places where Maven uses the "for = foo.withBar(bar)"
   pattern, and probably improves performance as well.

Maven 4 wasn't designed with records from the ground because the upgrade 
from Java 8 to Java 17 came too late in Maven 4 history (most of Maven 
API was already in place when the upgrade was done). However, even if we 
anticipated records, we would be forced to implement the "for = 
foo.withBar(bar)" pattern anyway because we cannot use JEP 468 (Derived 
Record Creation) yet. Removing that pattern in Maven 5 (if we choose to 
do so) would be another compatibility break.


Finally, after completion of the work in Maven 4 for better support of 
Java modules, I hope to propose a modularisation of Maven 5 itself. 
Again it may bring simplifications such as removing the need for 
plexus-classworlds. But it may be another source of incompatibility.


In summary, while I agree that there are issues with Maven 4 API, those 
issues may be nuanced in the perspective of an hardly avoidable 
compatibility break in (maybe) Maven 5 anyway.


    Martin


Le 13/02/2026 à 16:53, Elliotte Rusty Harold a écrit :

IMHO Maven 4.0 is not close to ready for release. The most serious
issue is the change of namespace. That's a major mistake that will
cause large problems for developers, especially those who use tools
other than Maven itself.

Second most serious issue is finalization of APIs. @Experimental
features need to be committed to or removed.

Similarly APIs have been deprecated but not documented with
replacement. That also needs to be finished.

Finally  much of the new API is unnecessarily complex with unneeded
separation of basic functionality like URLNormalizer into separate
interfaces, implementations, services, and default implementations
when all that’s needed is one single class with a few static methods.

All of this can and should be fixed before release. Much of it cannot
be fixed after release.

There’s an old saying about undergraduate papers: they’re never
finished, just submitted when the deadline comes. That’s what’s going
on here. Maven 4 isn’t close to a finished product, and it’s not clear
it has the resources or will to be finished, so there’s an urgency to
push something out the door, ready or not. However, pushing it out in
an unfinished state risks doing severe damage to the developer
community and Maven’s reputation. It is better to ship nothing than to
ship a half-baked product, discouraging as that is to the people who
have been working on it.

Re: [Discussion] What needs to be done for 4.0.0 GA?

2026-02-13 Thread Elliotte Rusty Harold 
On Fri, Feb 13, 2026 at 5:28 PM Henning Hoefer
 wrote:

> Maven 4.0 improves a lot of things, it absolutely should be released. If
> the APIs aren't perfect, there's always a Maven 4.1. And if bigger things
> need fixing, just make a Maven 5. But not releasing anything doesn't help
> anybody.

Not all issues are created equal.There are things we can add later if
we don't have them now, but more important are the things we can't
change after we ship them. That includes essentially all public API.
Better not to have it at this stage than to have the wrong thing, and
we have way too many of the wrong things in the Maven 4 codebase. A
lot of this is fix it now or live with the pain for likely as long as
Maven exists or we do, whichever comes first.

-- 
Elliotte Rusty Harold
[email protected]

-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Re: [Discussion] What needs to be done for 4.0.0 GA?

2026-02-13 Thread Henning Hoefer 
Well, *my* pet-peeve regarding transitive dependencies (#10
786
, formerly known as MNG-8099
) is also
not in, but I would never think that Maven 4 should be delayed because of
that. :-)

If you want to wait until every last issue is resolved, you're simply never
going to ship anything. Another old saying: Perfect is the enemy of good.
Software, especially collaborative efforts, will *always* be "undergrad
papers". And that's how open source (and science) moves forward.

Maven 4.0 improves a lot of things, it absolutely should be released. If
the APIs aren't perfect, there's always a Maven 4.1. And if bigger things
need fixing, just make a Maven 5. But not releasing anything doesn't help
anybody.

Just my 0,02€...

Now back to the actual topic of this thread:
I'm missing some step for verification of the new release "in the wild",
with as many different projects as possible.
Aren't there any statistics on how often the RCs got used?

- Henning


Am Fr., 13. Feb. 2026 um 16:54 Uhr schrieb Elliotte Rusty Harold <
[email protected]>:

> IMHO Maven 4.0 is not close to ready for release. The most serious
> issue is the change of namespace. That's a major mistake that will
> cause large problems for developers, especially those who use tools
> other than Maven itself.
>
> Second most serious issue is finalization of APIs. @Experimental
> features need to be committed to or removed.
>
> Similarly APIs have been deprecated but not documented with
> replacement. That also needs to be finished.
>
> Finally  much of the new API is unnecessarily complex with unneeded
> separation of basic functionality like URLNormalizer into separate
> interfaces, implementations, services, and default implementations
> when all that’s needed is one single class with a few static methods.
>
> All of this can and should be fixed before release. Much of it cannot
> be fixed after release.
>
> There’s an old saying about undergraduate papers: they’re never
> finished, just submitted when the deadline comes. That’s what’s going
> on here. Maven 4 isn’t close to a finished product, and it’s not clear
> it has the resources or will to be finished, so there’s an urgency to
> push something out the door, ready or not. However, pushing it out in
> an unfinished state risks doing severe damage to the developer
> community and Maven’s reputation. It is better to ship nothing than to
> ship a half-baked product, discouraging as that is to the people who
> have been working on it.
>
> On Thu, Feb 12, 2026 at 5:10 PM Matthias Bünger 
> wrote:
> >
> > Good evening everybody,
> > last week a small number of commiter and PMC had a chat about the
> > current situation about Maven 4.0.0.
> > Nobody of the people attended was aware of any outstanding blocking
> > issues, but also nobody could precicle say what else needs to be done
> > for a GA release. As a result we collected some points on a wiki page
> [1].
> >
> > Today Benjamin asked me to send a mail to the list, to gather feedback,
> > if we missed anything . Do you agree with the points on the list or do
> > you see any (and if yes, which) blocker that needs to be done, before we
> > can consider a 4.0.0 GA?
> >
> > Please note: This discussion should focus on "What's need to be done for
> > 4.0.0". It's not about discussions about will there new RC or was RC5
> > the last RC. This can be discussed when we have a complete (as possible)
> > list of TO-DO's. So please avoid to restart any discussion about
> > alpha/beta/RC versions in this thread. What happend, happend (including
> > new features, like Maven Update tool, during RC phase) - thank you.
> >
> > Matthias
> >
> > [1]:
> >
> https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0+GA+checklist
> >
> >
> > -
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
>
>
> --
> Elliotte Rusty Harold
> [email protected]
>
> -
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

Re: [Discussion] What needs to be done for 4.0.0 GA?

2026-02-13 Thread Elliotte Rusty Harold 
IMHO Maven 4.0 is not close to ready for release. The most serious
issue is the change of namespace. That's a major mistake that will
cause large problems for developers, especially those who use tools
other than Maven itself.

Second most serious issue is finalization of APIs. @Experimental
features need to be committed to or removed.

Similarly APIs have been deprecated but not documented with
replacement. That also needs to be finished.

Finally  much of the new API is unnecessarily complex with unneeded
separation of basic functionality like URLNormalizer into separate
interfaces, implementations, services, and default implementations
when all that’s needed is one single class with a few static methods.

All of this can and should be fixed before release. Much of it cannot
be fixed after release.

There’s an old saying about undergraduate papers: they’re never
finished, just submitted when the deadline comes. That’s what’s going
on here. Maven 4 isn’t close to a finished product, and it’s not clear
it has the resources or will to be finished, so there’s an urgency to
push something out the door, ready or not. However, pushing it out in
an unfinished state risks doing severe damage to the developer
community and Maven’s reputation. It is better to ship nothing than to
ship a half-baked product, discouraging as that is to the people who
have been working on it.

On Thu, Feb 12, 2026 at 5:10 PM Matthias Bünger  wrote:
>
> Good evening everybody,
> last week a small number of commiter and PMC had a chat about the
> current situation about Maven 4.0.0.
> Nobody of the people attended was aware of any outstanding blocking
> issues, but also nobody could precicle say what else needs to be done
> for a GA release. As a result we collected some points on a wiki page [1].
>
> Today Benjamin asked me to send a mail to the list, to gather feedback,
> if we missed anything . Do you agree with the points on the list or do
> you see any (and if yes, which) blocker that needs to be done, before we
> can consider a 4.0.0 GA?
>
> Please note: This discussion should focus on "What's need to be done for
> 4.0.0". It's not about discussions about will there new RC or was RC5
> the last RC. This can be discussed when we have a complete (as possible)
> list of TO-DO's. So please avoid to restart any discussion about
> alpha/beta/RC versions in this thread. What happend, happend (including
> new features, like Maven Update tool, during RC phase) - thank you.
>
> Matthias
>
> [1]:
> https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0+GA+checklist
>
>
> -
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>


-- 
Elliotte Rusty Harold
[email protected]

-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Re: [Discussion] What needs to be done for 4.0.0 GA?

2026-02-13 Thread Martin Desruisseaux via dev 

Hello Mathias

Thanks for creating this list. On the "blockers with no known 
workaround" item, I have this pull request which could be merged if 
approved. It applies only to projects using module source hierarchy. 
Classical Maven projects are not impacted, so this change should not be 
visible to the vast majority of current users. But it is necessary for 
continuing the work on module hierarchy at the Maven JAR plugin level.


   https://github.com/apache/maven/pull/11639

And the following pull request is needed for resources management. 
Again, it applies only to projects using module source hierarchy. Maybe 
more important, it also checks that a modular project is not malformed. 
I think that it is better to be strict at GA release time rather than 
making the checks stricter in a subsequent release, which could be a 
compatibility break:


   https://github.com/apache/maven/pull/11700

Thanks,

    Martin


Le 12/02/2026 à 18:10, Matthias Bünger a écrit :

Good evening everybody,
last week a small number of commiter and PMC had a chat about the 
current situation about Maven 4.0.0.
Nobody of the people attended was aware of any outstanding blocking 
issues, but also nobody could precicle say what else needs to be done 
for a GA release. As a result we collected some points on a wiki page 
[1].


Today Benjamin asked me to send a mail to the list, to gather 
feedback, if we missed anything . Do you agree with the points on the 
list or do you see any (and if yes, which) blocker that needs to be 
done, before we can consider a 4.0.0 GA?


Please note: This discussion should focus on "What's need to be done 
for 4.0.0". It's not about discussions about will there new RC or was 
RC5 the last RC. This can be discussed when we have a complete (as 
possible) list of TO-DO's. So please avoid to restart any discussion 
about alpha/beta/RC versions in this thread. What happend, happend 
(including new features, like Maven Update tool, during RC phase) - 
thank you.


Matthias

[1]: 
https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0+GA+checklist

Re: [Discussion] What needs to be done for 4.0.0 GA?

2026-02-13 Thread Maarten Mulders 

Hi Matthias, Benjamin,

Thanks for creating such a list. With large and much anticipated 
releases like these, I think it's good to have a plan so we will not 
forget the less-obvious things.


As a point to consider, would it make sense to contact ASF Infra 
upfront? As far as I know, they administer some Jenkins build machines. 
If so, they might want to equip those with the upcoming Maven 4.


Thanks,


Maarten

On 12/02/2026 18:10, Matthias Bünger wrote:

Good evening everybody,
last week a small number of commiter and PMC had a chat about the 
current situation about Maven 4.0.0.
Nobody of the people attended was aware of any outstanding blocking 
issues, but also nobody could precicle say what else needs to be done 
for a GA release. As a result we collected some points on a wiki page [1].


Today Benjamin asked me to send a mail to the list, to gather feedback, 
if we missed anything . Do you agree with the points on the list or do 
you see any (and if yes, which) blocker that needs to be done, before we 
can consider a 4.0.0 GA?


Please note: This discussion should focus on "What's need to be done for 
4.0.0". It's not about discussions about will there new RC or was RC5 
the last RC. This can be discussed when we have a complete (as possible) 
list of TO-DO's. So please avoid to restart any discussion about alpha/ 
beta/RC versions in this thread. What happend, happend (including new 
features, like Maven Update tool, during RC phase) - thank you.


Matthias

[1]: https://cwiki.apache.org/confluence/display/MAVEN/ 
Maven+4.0.0+GA+checklist



-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]




-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]