Why use semver at all? Since any change in the model breaks compatibility then isn't a natural number more appropriate?
Delany On Sat, 28 Mar 2026, 16:15 Mirko Friedenhagen, <[email protected]> wrote: > > Mit freundlichen Grüßen > Mirko Friedenhagen > — > > Am 28.03.2026 um 16:40 schrieb Fabrice Bauzac <[email protected]>: > > The problem if you change the namespace, is that certain tools that > > are currently tuned and working well with {MavenModel4.0.0}dependency > > will need changes when told to work on a different element like > > {MavenModel4.1.0}dependency. That seems like unnecessary breakage, > > burden and additional work to me, especially if you want 4.0.0 and > > 4.1.0 to have the same general structure... > Hi, > > I would think this is an advantage. They are basically not the same though > they look similar. > Theoretically 4.2.x could finally use a shortened dependency definition, > which seems to be one of the major things people find ugly compared to e.g. > gradle. > Additionally fully embraced it would allow more elements in other > namespaces as well in the same file. > Versioning is not semver compatible, though. Model 4.1.0 is not > backwards-compatible to 4.0.0 so theoretically it should get a major bump. > > > XML Schema Definition (XSD) is useful for validation and completion. > > It is one of the standard ways to do it. It is not useful for most > > tooling, except for validation and completion. It is not mandatory. > > It simply maps each namespace like {MavenModel4.1.0} to a downloadable > > URL containing the schema (or to a local file containing the schema). > As you say, it is a standard way and so valuable. > > > My take on XSD is that it can be used by Maven to run a standard XML > > validator. However, it is optional; also, the schema URL may point to > > a local file in a random local directory. So I don't think it is a > > good idea for Maven to deduce anything from the schema URL, which may > > be present or absent or have different values. I think Maven should > > instead rely on <modelVersion> alone. And the XSD information should > > remain optional, so people who don't need it can remove it... > Here I would disagree: either use model version or XSD. Otherwise you may > have contradicting information. > > > > Thanks! > > > > Best regards > > Fabrice > > > > > >> Le ven. 27 mars 2026 à 12:03, Maarten Mulders <[email protected]> > a écrit : > >> 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] > > > > --------------------------------------------------------------------- > > 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] > >
