Hi all,
I personally only care about the state of Maven API for plugin
maintainers (including the Maven team). It should be clear and
documented why the new API is ther, what it looks like / how it is used
and how to upgrade to it. As mentioned several times and also added by
Gerd to the "open To Dos for 4.0.0 list" not even our plugins are in
line with the API and there a breaking changes between literally every
beta/rc version. I offered several times to write documentation about
this if someone tells me what I have to write, because I have no clue
about the plugin API (neither for Maven 3 or 4).
I don't care about namespace changes in the build.pom. The consumer POM
is unchanged so it is the same since Maven 2 and the ecosystem can work
with it.
I see the possibilty that we have to do bigger changes before we are
fine for a Maven 4. And maybe we need to be brave / honest enough to go
back from RC phase to beta if this is required - even if it might raise
the "danger" of lurkers coming out of the dark to restart discussion to
add other things, like Java 21 or merge current 4.1. into 4.0 together
to have mixings from the 4.0.0 start.
Other topic: I know that there is nothing like "benevolent dictator" in
ASF project, but I have the feeling that we need something like this to
somehow end discussions and be it only to decide to start a binding vote.
Matthias
Am 14.02.2026 um 10:24 schrieb Maarten Mulders:
Hi all,
A few days ago, Matthias started a thread [1] to identify what needs
to be done before we could release Maven 4.0.0. He explicitly asked
not to reopen previous discussions in that thread - that's why I'm
opening a new one.
In that thread was a reply from Elliotte where he raised his concerns
on a couple of issues in the current codebase. I will try to summarise:
1. Maven 4.0.0 should not come with an XML namespace change.
2. We cannot introduce "experimental" API's; similarly, we can't
"deprecate" API's without proper documentation about their replacement.
3. Unnecessary complication in basic functionality.
Elliotte, please feel free to elaborate and/or refer back to earlier
mailing list threads where those things have been raised.
The thing I would like to discuss in this thread: **do we feel
comfortable releasing Maven 4.0.0 in this state?**
My personal opinion on the above three points:
1. I do not have enough knowledge to judge on this. When in doubt, do
not proceed - I would like to hear the experts voices on this before
deciding to cut a release.
2. I very much agree here. If we can't even say that usage of the
(deprecated) method-X now needs to call the (new) method-Y, then who
can? We owe it to people building on top of Maven to provide them with
guidance. Also, releasing "experimental" API's is not a sign of "yes,
this is an improvement of what we had and you should all use this".
It's been around for well over a year in various beta and RC releases,
I think we need to decide if we keep them or remove them.
3. This personally worries me the least, *as long as those interfaces
are not part of our public API/SPI*. If they are only internal, we
could safely remove them and simplify in 4.0.x or 4.x.y. If those
interfaces are for public consumption, then we might want to
reconsider if they could become non-public.
Curious to hear your thoughts on this. As much as I would love to see
Maven 4 go public, I *don't* want to ship software we know is in a
broken state.
Thanks,
Maarten
[1] https://lists.apache.org/thread/d07wpod69spl6trt1cy5ykzs2971414j
---------------------------------------------------------------------
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]
