So Maven would need to "manually" parse the pom, check the model version and analog to Java tell people immediately, that a newer version is needed before actually doing the real lifecycle/dependency resolution stuff?
Mit freundlichen Grüßen Mirko Friedenhagen -- Am 14.03.26 um 17:23 schrieb Hervé Boutemy > I don't get the question > > we are talking about what namespace should we define for > https://maven.apache.org/ref/4.0.0-rc-5/api/maven-api-model/maven.html > which is the new schema https://maven.apache.org/xsd/maven-4.1.0.xsd > = Maven 4.0.0 build POM > > For Maven 4 consumer POM, no choice, it's Maven 3 POM: > https://maven.apache.org/ref/3.9.13/maven-model/maven.html > > > IIUC, logic promoted by Elliote is that there is one unique namespace > whatever > the version of schema, tools detect the xsd to adapt to new schema version, > not to "versioned" namespace > > so there is no notion of "extending existing namespace": there is one unique > namepsace, with multiple schema versions > > Le vendredi 13 mars 2026, 19:20:18 CET Sylwester Lachiewicz a écrit : > > 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] > > > > > > --------------------------------------------------------------------- > 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]
