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