I don't get the question we are talking about what namespace should we define for https://maven.apache.org/ref/4.0.0-rc-5/api/maven-api-model/maven.html which is the new schema https://maven.apache.org/xsd/maven-4.1.0.xsd = Maven 4.0.0 build POM
For Maven 4 consumer POM, no choice, it's Maven 3 POM: https://maven.apache.org/ref/3.9.13/maven-model/maven.html IIUC, logic promoted by Elliote is that there is one unique namespace whatever the version of schema, tools detect the xsd to adapt to new schema version, not to "versioned" namespace so there is no notion of "extending existing namespace": there is one unique namepsace, with multiple schema versions Le vendredi 13 mars 2026, 19:20:18 CET Sylwester Lachiewicz a écrit : > How to distinguish that with option B pom is for maven 3 or Maven 4 build > pom for XML based tools? > Do we have easy way to extend existing namespace? > > Sylwester > > czw., 12 mar 2026, 16:15 użytkownik Elliotte Rusty Harold < > > [email protected]> napisał: > > On Sat, Mar 7, 2026 at 5:13 PM Hervé Boutemy <[email protected]> wrote: > > > 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 > > > > This is essentially correct. I strongly recommend option B, keep > > http://maven.apache.org/POM/4.0.0 from Maven 3 for Maven 4.x, 5 etc... > > > > > 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] > > > > -- > > Elliotte Rusty Harold > > [email protected] > > > > --------------------------------------------------------------------- > > 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]
