Howdy, just to throw in my 5 cents for those discussion model namespaces, which was (AFAIK) brought in by this PR: https://github.com/apache/maven/pull/703
And my 5 cents are: you are folks 4 years late. T On Thu, Mar 12, 2026 at 2:55 PM Maarten Mulders <[email protected]> wrote: > > Hi Hervé, > > Agreed, at some point we must make a decision and move forward. Allow me > to go through your email point by point. > > 1. Nothing to comment on. > > 2. Correct. For what I understand of it: an element in XML is not only > defined by its name, but by its name and the namespace it lives in. Put > differently, <groupId> in the http://maven.apache.org/POM/4.0.0 > namespace is not the same thing as <groupId> in the > http://maven.apache.org/POM/4.1.0 namespace, even though they happen to > have the same name. XML tools and libraries will consider them > different, unrelated things. > > 3. I think B or C would be best. Maybe I like C oer B, so that we > (hopefully) never again confuse a version number in a namespace with an > actual version of the schema. As an example, look at the Servlet > specification. The namespace is https://jakarta.ee/xml/ns/jakartaee, > there is no version number. The location of the schema is versioned, > though: https://jakarta.ee/xml/ns/jakartaee/web-app_6_0.xsd. > > 4. Although A is the least work *for us*, it makes using pom.xml for > other consumers/tools probably harder - as there may come a > http://maven.apache.org/POM/4.2.0 etc., which means they will always > have to catch up. I cannot comment on the complexity of moving Maven 4.0 > to http://maven.apache.org/POM - hopefully someone else can comment on that. > > Personally, I would not opt for dropping XML. I am happy with what it > gives us and I see no reason to get rid of it. We only must take care to > use it as it is designed to be used. > > > Thanks, > > > Maarten > > > On 07/03/2026 18:13, Hervé Boutemy 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 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] > > > > > --------------------------------------------------------------------- > 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]
