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]
