Hi My 2cts would be
1. this is the whole goal of the consumer pom work did in maven 3 so the correct phrasing is "we must come with a new namespace", what is also true is "we must support maven 4.0.0 model version and older namespace" => we are good 2. goal was to cover at least jar packaging/lifecycle plugins, if we do we can drop experimental and enhance it in later releases but there was a chicken egg thing there doing RC so can be worth a pass to validate it since not everything is 100% done but think we prove we can start with it and we know how to enrich it => we are good if we do accept that (and to be honest if we don't nobody will start writing maven 4 plugins except us so will not help) 3.100% a person related design, what can look good and trivial for somebody can look overcomplicated for someone else. Maven 3 design can look totally broken (and it can be a justifiable view) as well as over complex (plexus, resolver, surefire, lifecycle/packaging, ...). Question is not "is it complex" but is it justifiable IMHO and is it clear (if we add a new one can we be consistent). Think we are good but can be worth a doc about the design for future reference. Hope it makes sense. 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 à 10:25, Maarten Mulders <[email protected]> a écrit : > 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] > >
