sorry, I don't get what has been done, "years ago": can you explain?
and TBH, I don't get what changing namespace value really breaks beyond some very theoretical aspect: so changing or not changing in one or the other direction, what does it break? Le vendredi 13 mars 2026, 18:41:39 CET Benjamin Marwell a écrit : > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
