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] > >
