It is the same in termes of info, you still must set the pom schéma version somewhere.
Min diff is in one case you keep the xml being rigid and without any namespace so parseable without a full xml parser and the other case you start using namespaces so potentially other namespaces extensions if we want - today we ARE stucked on that and require external files for extensions or properties which dont scale well. Inference is our infernal impl/detail nobody care about but core dev and it can change any time without impacting most users so I wouldnt emphasis it. Only real question is do we want to use namespaces or still ignore xml to lower parser cost from my window. 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, 10:52, Hervé Boutemy <[email protected]> a écrit : > I'm not sure the feature is understood: modelVersion inference is there to > not > being forced to write a XML element when a XML namespace is set > > so with Maven 3, we are forced to write: > <project> > <modelVersion>4.0.0</modelVersion> > [and groupId, artifactId, version at minimum] > </project> > and the addition of a XML namespace does just add more characters > > with Maven 4, if we configure a namespace, we can simplify: > <project xmlns="http://maven.apache.org/POM/4.1.0";> > [and groupId, artifactId, version at minimum] > </project> > modelVersion field value (required by Maven in-memory model for Maven 3 > compatibility) > > > and as any other Maven feature when there are default values, inference > works > in a very natural way: it happens as a default value if not explicitely > written > > > > at the cost of supporting a xml parser client side....in 2026 > this part I don't get: it's not about XML parser, it's about effective > model > building, with inheritance, and so on, and now inference > > > People can play with this inference feature, it's the bast way to learn > this > new feature in a more complete way than read and half-remember: > take a minimal pom.xml like: > <project xmlns="http://maven.apache.org/POM/4.1.0";> > <!--modelVersion>4.0.0</modelVersion--> > <groupId>com.example</groupId> > <artifactId>parent</artifactId> > <version>1.0.0-SNAPSHOT</version> > <description>modelVersion = ${project.modelVersion}</description> > </project> > > and run "mvn help:effective-pom | grep modelVersion" to see the result > when you > remove namespace, un-comment modelVersion, with Maven 3 or Maven 4 (since > alpha-6) > > very natural, very smart: just a new habit of simplification that users > will > have to discover that they can enjoy on less XML line with a stupid value. > > Regards, > > Hervé > > > Le dimanche 22 mars 2026, 09:20:24 CET Romain Manni-Bucau a écrit : > > 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-978178847 > > 3064> 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-97817884 > > > 7 > > > > > > >> 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] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
