this is digressing from initial objective = decide what to do in Maven 4.0.0 and more precisely on the XML namespace
this XML napespace topic seems tohave been reviewed in every direction: now it's time to decide I'll start a vote with 2 options: A. keep 4.1.0 namespace, and associated modelVersion inference B. revert to 4.0.0 namespace, and forced explicit modelVersion this will close this long debate Regards, Hervé Le mardi 31 mars 2026, 22:02:08 CEST Romain Manni-Bucau a écrit : > Nop, outside resolver type and classifier are always reversed and btw > type=extension almost every where but in maven core. > Doesn't change much that we now have a unique not deprecated syntax which > would be our de facto standard to reference an artififact. > Scope and type could stay split. > > Anyway out of scope for maven 4 not? So we drop the topic? > > > 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 mar. 31 mars 2026, 21:14, Tamás Cservenák <[email protected]> a écrit : > > Nope, and sorry to nitpick, but: > > classifier is OK (is part of Artifact spec) > > type and scope is not OK (is not specd anywhere) > > > > T > > > > On Tue, Mar 31, 2026 at 9:03 PM Romain Manni-Bucau > > > > <[email protected]> wrote: > > > It is standard in the sense we do have a central syntax now and we do > > > > lead > > > > > it by design, ack that type/classifier are a mess out there and we do > > > > miss > > > > > extension cleanly defined but we have a workaround for it. > > > > > > > > > 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 > > 73064> > > > Javaccino founder (Java/.NET service - contact via linkedin) > > > > > > Le mar. 31 mars 2026, 19:27, Tamás Cservenák <[email protected]> a > > > > écrit : > > > > Howdy, > > > > > > > > With consumer pom we can (locally) use any lingo we want. In fact, > > > > Takari's Polyglot Maven already showed us a "tighter" XML format (the > > > > short-XML) POM format: > > > > https://github.com/takari/polyglot-maven/tree/master/polyglot-xml > > > > > > > > And no, it is not standardized. Or in other words, what IS > > > > standardized is _Artifact_ as string form of > > > > '<groupId>:<artifactId>[:<extension>[:<classifier>]]:<version>' > > > > BUT, if you think about it, in Maven (in POM) you _never_ talk about > > > > Artifact directly, you always talk about Dependency, Plugin, etc > > > > So, while the G:A:V could work for plugins, but could not work for > > > > dependencies.... those always have a "purpose" (type) among other > > > > things like scope. > > > > And those are NOT standardized at all. > > > > > > > > JBang does add some types supported by Maven4, like "fatjar" using @ > > > > symbol, fx `jbang > > > > eu.maveniverse.maven.plugins:toolbox:0.15.6:cli@fatjar` > > > > (fatjar type has property set `includesDependencies=true`, so is an > > > > uber JAR and does not need any dependencies, despite GAV:pom would > > > > tell it does) > > > > > > > > > > > > HTH > > > > T > > > > > > > > On Tue, Mar 31, 2026 at 6:17 PM Romain Manni-Bucau > > > > > > > > <[email protected]> wrote: > > > > > maybe we should move the syntax thread to a new maven 4.2/5 desired > > > > > > > > feature > > > > > > > > > one since it is unlikely it happens in 4.0.0 now? > > > > > > > > > > side note: g:a:v is almost standardized using resolver API (even > > > > > with > > > > > classifier/extension-type) so for maven users it wouldnt be worse > > > > than > > > > > > > splitting in attributes IMHO > > > > > > > > > > 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 > > 73064> > > > > > Javaccino founder (Java/.NET service - contact via linkedin) > > > > > > > > > > Le mar. 31 mars 2026 à 18:02, <[email protected]> a écrit : > > > > > > Tangent from an end user: > > > > > > > > > > > > On Sat, Mar 28, 2026 at 06:04:24PM +0000, Fabrice Bauzac wrote: > > > > > > > You can change parts of the structure indeed, e.g. instead of > > > > > > > > > > > > > > #+begin_src xml > > > > > > > > > > > > > > <dependency> > > > > > > > > > > > > > > <groupId>g</groupId> > > > > > > > <artifactId>a</artifactId> > > > > > > > <version>v</version> > > > > > > > > > > > > > > </dependency> > > > > > > > > > > > > > > #+end_src > > > > > > > > > > > > > > have > > > > > > > > > > > > > > #+begin_src xml > > > > > > > > > > > > > > <dependency>g:a:v</dependency> > > > > > > > > > > > > > > #+end_src > > > > > > > > > > > > > > Which is fine. But please note that doing so does not require a > > > > > > > change of namespace. > > > > > > > > > > > > Please, no. Use XML as it was designed: > > > > > > > > > > > > <dependency groupId='g' artifactId='a' version='v'/> > > > > > > > > > > > > If making a clean break, there are lots of places where the POM > > > > schema > > > > > > > > can be made more precise without introducing additional layers of > > > > > > parsing. > > > > > > > > > > > > -- > > > > > > Mark H. Wood > > > > > > Lead Technology Analyst > > > > > > > > > > > > University Library > > > > > > Indiana University Indianapolis > > > > > > 755 W. Michigan Street > > > > > > Indianapolis, IN 46202 > > > > > > 317-274-0749 > > > > > > library.indianapolis.iu.edu > > > > > > > > > > > > ORCiD: 0000-0002-9558-3768 > > > > > > > > --------------------------------------------------------------------- > > > > 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]
