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.
