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-9781788473064>
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-9781788473064
> >
> > 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]
>
>

Reply via email to