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]
