Theoretically you may define multiple schemes in XML, so you may mix different schemes. One of the schemes may be used without the prefix. So something like: <project xmlns="http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"; xmlns:m4_1="http://maven.apache.org/POM/4.1.0"; xsi:schemaLocation="http://maven.apache.org/POM/4.1.0 https://maven.apache.org/xsd/maven-4.1.0.xsd"; >
With the above you then could define something like: <m4_1:subprojects></m4_1:subprojects> I once tried to mix pom.xml with xhtml but Maven did not react very well back then :-). Mit freundlichen Grüßen Mirko Friedenhagen — Mit freundlichen Grüßen Mirko Friedenhagen — > Am 13.03.2026 um 19:23 schrieb Sylwester Lachiewicz <[email protected]>: > 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]
