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]
