The problem with deferring the change is that the longer we wait the harder this becomes. Perhaps it becomes impossible. Today we are at a possibly unique point where Maven has effectively one namespace and one modelVersion in production, aside from extremely old artifacts that very few projects are using in production any more. We can keep the namespace the same and revise the model version. Once there are multiple namespaces in active use, it won't be possible to unify on a single namespace.
Once we do have a single namespace, developers can use standard XML tools like XSLT, XQuery, XPath, XInclude, DOM, and more to process POM files. It is so much easier to use these than to try to rely on Maven's own parsing code. This is particularly useful for any sort of analytics like tracking what's in your project's dependency tree. Yes, we'll still have the issue with old POMs that don't declare any namespace, but at least the newer modelVersion 4.1.0 POMs will be tractable. Don't get too hung up on exactly what the namespace URI is. It's really just an opaque string. It's unfortunate that the 4.0.0 in the namespace URI doesn't match Maven or model versions, and really that' it's in the namespace at all, but that's not something we can or should fix now. At the end of the day it's just a string, and as long as the string is constant over time, it's all good. As well as the benefits of having a single well-defined namespace, we also get the benefits of decoupling namespace from modelVersion. As is, the namespace changes from one modelVerskon to the next. The namespace is tied to the modelVersion, and the modelVersion can be inferred from the namespace. There's code in the project that does exactly this. In which case, why do we have both? This just introduces a new class of confusing errors where the namespace doesn't match the modelVersion. Our code gets simpler if a namespace is a namespace and a modelVersion is a modelVersion, and we can change one without changing the other. On Tue, Jul 22, 2025 at 12:47 PM Guillaume Nodet <gno...@apache.org> wrote: > > Hi all, > > I'm writing to initiate a discussion about an important decision regarding > Maven 4.0's namespace strategy. We have two competing approaches > represented by different pull requests, and the *primary question is about > timing and acceptable breakage* for this release cycle. > Background > > As we approach Maven 4.0 GA (currently at RC-4), we have two PRs that > represent different philosophies: > > - *PR #2475*: Create a new modelVersion 4.2.0 (my approach, targeting > 4.1.0/master) > - *PR #10952*: Keep Maven Namespace the same (@elharo's approach) > > The Core Issue: Timing vs. Technical Merit > > *My position:* I don't disagree with @elharo's proposed change from a > technical standpoint. The benefits are: > > - Adheres to XML namespace best practices > - Makes XML processing tooling easier by not having to convert between > namespaces > > *However*, this represents a *major breaking change*. While my PR targets > 4.1.0 (master branch), since we already have a stable branch for 4.0.0, the > timing question remains critical for our overall versioning strategy. > My Proposal: Defer to Maven 5.0 > > Instead of rushing this change into 4.0, I propose we: > > 1. *Continue with my approach for Maven 4.1.0* (new modelVersion 4.2.0, > already targeting master) > 2. *Plan properly for Maven 5.0* with a brand new namespace that we > would then consider stable > 3. *Design the Maven 5.0 namespace from the ground up* with long-term > stability in mind > > This approach would give us the benefits @elharo is seeking while allowing > proper planning, testing, and ecosystem preparation. > Key Questions for the Community > > 1. *Timing*: Should we introduce a major breaking change in the 4.x > series, or wait for 5.0? > 2. *Risk tolerance*: What level of ecosystem disruption is acceptable > for a 4.x release? > 3. *Long-term vision*: Would a properly planned Maven 5.0 namespace > overhaul better serve our goals? > > I'm interested in hearing the community's thoughts on this timing vs. > technical merit trade-off. > > Best regards, > Guillaume Nodet > ------------------------------ > > *References:* > PR #2475: https://github.com/apache/maven/pull/2475 > PR #10952: https://github.com/apache/maven/pull/10952 -- Elliotte Rusty Harold elh...@ibiblio.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
