I agree with Tamas. This is already done, years ago. Also, this would break yet another release candidate, and IntelliJ already implemented support for the new model version, and probably netbeans as well. Since mvn4 is available as beta and rc for years now, I don't think we would break major utilities. Even then, users and utility providers could stick with mvn3 for a while.
Let's not break mvn4 again. - Ben On 12 March 2026 15:12:54 CET, "Tamás Cservenák" <[email protected]> wrote: >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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
