Think it is a sane summary Hervé but also agréé with David that we can ditch model version now (since namespace opens doors for the future model version will never by design at the cost of supporting a xml parser client side....in 2026).
+1 for a vote Romain Manni-Bucau @rmannibucau <https://x.com/rmannibucau> | .NET Blog <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> Javaccino founder (Java/.NET service - contact via linkedin) Le dim. 22 mars 2026, 05:12, David Jencks <[email protected]> a écrit : > I’m still in the peanut gallery, but I don’t understand any possible way > providing two ways to specify the model version makes any sense. > Let’s say I use both, and specify different versions. How should I guess > which wins? I thought the idea of specifying something unambiguously in one > place was a generally accepted principle of good design. > > I was really hoping the namespace change would be rolled back. I haven’t > seen any explanation of how it is useful. > > David Jencks > Sent from my iPhone > > > On Mar 21, 2026, at 7:34 PM, Hervé Boutemy <[email protected]> > wrote: > > > > I went on improving documentation for modelVersion field: > > - Maven 3:https://github.com/apache/maven/pull/11809 > > - Maven 4.0.x: https://github.com/apache/maven/pull/11810 > > and I suppose once 4.0.x is merged, we'll do 4.1.x, that adds 4.2.0 > value for > > modelVersion: > > https://maven.apache.org/ref/4-LATEST/api/maven-api-model/maven.html > > > > my key learning in that journey is that in Maven 4, modelVersion can be > > inferred from namespace: I did not get it until now, really nice. It's > up to > > the parser to eventually do some inference to fill the field. > > > > This also lead me to rethink: reading one pom.xml or .pom file is nice, > but > > what is important from Maven perspective is effective POM = the model in > > memory, after inheritance, and now inference > > = the result of https://maven.apache.org/ref/3.9.14/maven-model-builder/ > > > > What is important for individual pom.xml read/update is IDE support, > with in- > > depth understanding of the path from individual file to effective model. > > > > > > so all in all, I'm starting to be convinced that > > 1. fixed or versioned namespace is 100% a style decision > > 2. we get a benefit from versioned namespace: modelVersion inference > > 3. AFAIK, IDEs did not object to that aspect of pom.xml vs effective > POM, no > > precise big trouble reported > > > > I updated the topic description in the tracking doc for Maven 4.0.0 GA: > > https://cwiki.apache.org/confluence/pages/viewpage.action? > > pageId=406620656#Maven4.0.0GAchecklist-Maven4Namespace > > > > Are the pros and cons sufficiently understood/documented now for > everybody? > > > > Any objection/topic to cover before launching a vote to make an > enlightened > > decision? > > > > Regards, > > > > Hervé > > > > > > Le lundi 16 mars 2026, 11:30:09 CET Romain Manni-Bucau a écrit : > >> it is where maven always had been weird-ish, it relies heavily on XML > but > >> doesn't actualy embrace XML - just cause of one line. > >> the impact is that if you need some extension configuration to inject in > >> the pom - natural compared to have pom.xml extension1.xml, > extension2.json > >> etc..., then you must use properties or plugin configuration even when > not > >> needed. > >> Guillaume made some enhancement on that but namespaces are designed for > >> that and don't have any issue nor maven has any nor any consuming tool > as > >> soon as they do parse XML. > >> The only issue we can get if we do want portable pom, ie extensionless > >> otherwise the pom is no more the only source of truth and all that is > >> pointless. > >> > >> So yes modelVersion can be used as a source but a namespace as well and > it > >> doesn't imply any remoting even using https://... since we do embed > xsd in > >> the project. > >> > >> So overall, from my window it is 100% a style decision. > >> > >> The only point which can weight there for me is if we do support > >> polygloting or we consider it is an extension we don't care about - I'm > >> fine both ways since it is broken in IDE anyway. > >> If we think it is a core/important feature, namespacing can make it > complex > >> for nothing and modelVersion is easier but it is the only real criteria > for > >> maven 4 IMHO, other points are wrong technically. > >> > >> Romain Manni-Bucau > >> @rmannibucau <https://x.com/rmannibucau> | .NET Blog > >> <https://dotnetbirdie.github.io/> | Blog < > https://rmannibucau.github.io/> | > >> Old Blog <http://rmannibucau.wordpress.com> | Github > >> <https://github.com/rmannibucau> | LinkedIn > >> <https://www.linkedin.com/in/rmannibucau> | Book > >> < > https://www.packtpub.com/en-us/product/java-ee-8-high-performance-978178847 > >> 3064> Javaccino founder (Java/.NET service - contact via linkedin) > >> > >>> Le lun. 16 mars 2026 à 11:08, Björn Raupach <[email protected]> a > écrit : > >>> Elliot, I don’t want to stir up a hornet’s nest, but could you give me > a > >>> specific example of where it would cause a problem? > >>> > >>> In Maven 3.9.x the namespace declaration never mattered in all the > >>> projects I used it with. I fail to understand why it matters in Maven > 4. > >>> > >>> All these allow Maven to execute and run: > >>> > >>> <project> > >>> > >>> <modelVersion>4.0.0</modelVersion> > >>> <groupId>com.mycompany.app</groupId> > >>> <artifactId>my-app</artifactId> > >>> <version>1</version> > >>> > >>> </project> > >>> > >>> <project xmlns="foo"> > >>> > >>> <modelVersion>4.0.0</modelVersion> > >>> <groupId>com.mycompany.app</groupId> > >>> <artifactId>my-app</artifactId> > >>> <version>1</version> > >>> > >>> </project> > >>> > >>> <project xmlns="xmlns=http://maven.apache.org/POM/4.0.0”> > >>> > >>> <modelVersion>4.0.0</modelVersion> > >>> <groupId>com.mycompany.app</groupId> > >>> <artifactId>my-app</artifactId> > >>> <version>1</version> > >>> > >>> </project> > >>> > >>> I admit that my expertise in XML is limited, but I worked with XML in a > >>> highly regulated environment. They used XML namespaces and schemas > >>> extensively. > >>> > >>> In that project, XML documents were a composition of many XML > documents, > >>> each with its own XML namespaces and schema. > >>> Every element and attribute hat do use a qualified name. > >>> The XML namespaces were used to avoid element names clashes, because > >>> some elements had the same name, but belonged to a different "XML > >>> vocabulary". > >>> Therefore, it made sense to qualify every element with its prefix. > >>> > >>> Isn’t this the only reason why we need namespaces in the first place? I > >>> have never seen a qualified name in any pom.xml in the last twenty > >>> years. > >>> > >>> The XML schema was used to verify the various XML documents that made > up > >>> the larger XML document. > >>> The schema ensured that the vocabulary, i.e. the sum of XML elements > and > >>> attributes for that part of the document was used correctly. > >>> Nothing more. While this was useful, the namespace itself was never > >>> verified using the XML schema. I don't think that's even possible. > >>> > >>> Namespaces do nothing more than avoid name collisions. Maven does not > >>> have a problem with names coming from different sources. > >>> > >>> Am 16.03.2026 08:20 schrieb Guillaume Nodet: > >>>> Regarding the namespace discussion, I'd like to better understand the > >>>> concrete difficulty with processing POMs that have different > >>>> namespaces. > >>>> > >>>> In XSLT, a simple namespace normalization pre-processing step handles > >>>> this: > >>>> > >>>> <xsl:template match="*"> > >>>> > >>>> <xsl:element name="{local-name()}" > >>>> > >>>> namespace="http://maven.apache.org/POM/4.0.0";> > >>>> > >>>> <xsl:apply-templates select="@*|node()"/> > >>>> > >>>> </xsl:element> > >>>> > >>>> </xsl:template> > >>>> > >>>> In XPath, you can use local-name(): > >>>> //*[local-name()='dependency'] > >>>> > >>>> Or in XPath/XSLT 2.0+, wildcard namespace matching: > >>>> //*:dependency > >>>> > >>>> I want to make sure we're weighing the actual cost accurately on both > >>>> sides > >>>> before making a decision. > >>>> > >>>> Guillaume > >>>> > >>>> > >>>> Le sam. 14 mars 2026 à 22:15, Elliotte Rusty Harold > >>>> <[email protected]> a > >>>> > >>>> écrit : > >>>>> On Sat, Mar 14, 2026 at 4:17 PM Hervé Boutemy <[email protected] > > > >>>>> > >>>>> wrote: > >>>>>> 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? > >>>>> > >>>>> I have said this before. I'm guess I'm going to have to say it again. > >>>>> The problems are not theoretical. I have personally spent extra > months > >>>>> of development on projects (which Google paid for at the time, so > >>>>> probably six figures worth of Google's money) because I could not use > >>>>> standard XML tooling like XSLT and XPath to process pom.xml files. > The > >>>>> specific reason was Maven not using namespaces as designed and > >>>>> documented in the Namespaces in XML specification. Adding new > >>>>> namespaces makes the problem worse. > >>>>> > >>>>> There are other tools I have never bothered to build because they'd > >>>>> simply be too challenging and expensive to create. > >>>>> > >>>>> There is no benefit to introducing new namespaces with every version > >>>>> of Maven and substantial cost. The burden of proof is on those who > >>>>> claim we should change the namespace and work against the design of > >>>>> XML namespaces. > >>>>> > >>>>> -- > >>>>> 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] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
