Keeping major close to maven version in the future can be valuable
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 dim. 29 mars 2026, 09:43, Delany <[email protected]> a écrit : > 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] > > > > >
