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-9781788473064> 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] > >
