I'm late to the discussion, but we need to close it I'll need clarity on this namespace topic, it's too vague to my old XML related knowledge, and define what concrete choices we have, as blocking forever is not an option.
1. the situation: Maven 3 POM xmlns="http://maven.apache.org/POM/4.0.0"; https://maven.apache.org/ref/3.9.13/maven-model/maven.html Maven 4 POM build xmlns="http://maven.apache.org/POM/4.1.0"; https://maven.apache.org/ref/4.0.0-rc-5/api/maven-api-model/maven.html 2. analysis: IIUC, changing the value from Maven 3 to 4 is a problem for XML-level tools, that recognize the value to adapt. And also changing in the future for every Maven 4.x version, as we currently implicitely will change again the namespace with a version number in the future is this analysis correct? (I'm interested into pointers to concrete problems for XML-level tools, as it remains vague to me) 3. options: A. continue as implemented B. keep http://maven.apache.org/POM/4.0.0 from Maven 3 for Maven 4.x, 5 etc... C. change Maven 4.0 to http://maven.apache.org/POM and stay with this value in the future any other option? 4. complexity of implementing options (from a Maven core perspective): are every option as easy to implement, or is any option complex to do? Doing a choice for this topic should not be that hard, with a few efforts from everybody or "just for fun", perhaps the only option is to drop XML to close this XML-specific complexity... Regards, Hervé On 2026/02/22 11:46:58 Maarten Mulders wrote: > Hi Elliotte, > > Thank you for your elaboration! It didn't click together for me earlier > but I think I now better understand your concern; this sentence > summarises it for me: "A group element is still a group element." > > As far as I know, being able to change namespaces was never the goal of > separating build and consumer POM. The goal was to be able to evolve the > schema of the POM that a developer uses to build the project, without > affecting those that consume the project. I think we could have done > that without changing XML namespaces. And I fully agree with Elliotte: > if we revert that change before Maven 4.0.0, it will be a lot easier > than trying to repair this after releasing 4.0.0. > > I know we aren't voting on this (yet). Nevertheless, I would say it's > better to ship Maven 4.0.0 a bit later but in a good shape, than > shipping it early with a known large defect. > > Thanks, > > > Maarten > > On 14/02/2026 23:46, Elliotte Rusty Harold wrote: > > On Sat, Feb 14, 2026 at 8:25 PM Romain Manni-Bucau > > <[email protected]> wrote: > >> > >> 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 > > > > > > No, that is the concern and that is not a resolution. The goal is to > > be able to use XML tools like XPath and XSLT to process pom files, > > both inside and outside Maven itself. By changing the namespace this > > becomes immensely more difficult because instead of adding a few new > > elements it's like we threw away all the existing elements and > > replaced every one with a new element. > > > > But this is not what we have done, or at least not what we should do. > > A group element is still a group element. A dependency element is > > still a dependency element. And so forth. These elements haven't > > changed so their names shouldn't have changed, and that includes the > > namespace. > > > > Many developers still confuse namespaces with schema versions, but > > that is not how namespaces were designed to work. In general the > > namespace should not change simply because a new version of a > > vocabulary has been released. In Maven's case that's what modelVersion > > is for. Releasing a new version of a vocabulary does not justify > > changing the namespace, and there is a large cost associated with > > doing so. > > > > > --------------------------------------------------------------------- > 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]
