Let me try to wrap up my current understanding of where we are:
1. The namespace is used to infer the model version.
2. The model version determines which inference Maven will apply when
reading the POM file from disk.
3. The POM file on disk can never describe the full model Project Object
Model, as many of that model is inferred and/or inherited.
Given 3. (and 2.) I think we should state: "understanding a POM file on
disk is not possible without using the Maven libraries that read, parse
and interpret it". This statement applies to any POM file, regardless of
whether it is XML or another format.
Q: Does that make sense?
I think a potential conclusion could be that support for tools outside
the Maven libraries to "understand" or "process" a POM file on disk is
not our priority or maybe not even our concern.
Q: Is that something we agree upon? Shoud we vote on this?
One more thing: In the XML world, we derive the model version from the
namespace. I will leave it in the middle if that is good or bad, that's
just how it works today. How is that supposed to work in other, non-XML
formats, that might not have the notion of namespaces?
Maarten
On 22/03/2026 10:52, Hervé Boutemy wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
