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]
