I'm well aware of the Takari Polyglot project. However I don't want to
spend time to rewrite it all to Maven 4. The Maven 4 architecture allows a
much better support for additional syntaxes by leveraging a new clear SPI
and the fact that we have the consumer POM and build POM. The build POM is
the original (non xml) POM, but the consumer POM is automatically
translated to XML.
Polyglot focuses more on using programming languages to read the POM, for
example groovy, clojure, ruby, scala. Xml and Yaml are the only two
"static" mappings. While some may find the dynamic one interesting, I
think the static ones are more useful, because they can more easily be
translated back from the model object to the syntax. Which is very useful
if you want to have tooling that can modify the pom.
FWIW, the implementation of the hocon and yaml extensions for Maven 4 only
consists in 2 classes: the first one is the actual ModelParser
implementation which reads the file and the delegate to the
MapModelReader. This class translates a recursive Map<String, Object> into
a Model object. The nice thing is that this class is completely generated
from the Modello model, and can be reused across all kind of "static"
mappings: JSON, YAML, HOCON, TOML, etc... Once a parser can parse the file
into an Map, we're done. So I want to limit my experimentation to things
that can be generated. Fwiw, I found a library which supports the 4
syntaxes above with a single api...
Anyway, one of the big drawbacks for these is that I don't think there is
any parser which could be easily extended to track locations the way we do
with XML. Or maybe Jackson for JSON (it can support a few fancy syntax
tricks, but not many and values must be quoted, which I find a bit
verbose...)
I may come back with an experiment for the XML. It should be fairly simple
to hack the existing template which generates the MavenStaxReader to
support attributes for elements which have a simple type, and support
<dependency gav="org.apache.maven.plugins:maven-compiler-plugin:3.11.0" />
instead of
<dependency groupId="org.apache.maven.plugins"
artifactId="maven-compiler-plugin" version="3.11.0" />
For properties or plugin config, the usual java properties syntax could be
used
<properties syntax="properties">
java.release = 17
maven-compiler.version = 3.11.0
</properties>
Or for plugin configuration:
<configuration syntax="properties">
skip = false
release = 17
</configuration>
Anyway, if any one is interested, there's definitely room for experiments.
Previously it would have required the creation of a modello generator, but
now a single file (velocity template) is needed, so feel free to give it a
try !
Le jeu. 6 mars 2025 à 19:12, Hervé Boutemy <hbout...@apache.org> a écrit :
>
> I see the interest of improving maintainability of build POM beyond what
has already been
> achieved with inference (did I say I loved your presentation [4] and this
term?)
> But as already expressed, I fear the risk of confusion and time taken...
>
>
> Your approach of not just discussing but providing concrete examples
based on
> implementation makes me hope we can get some good learning from this
re-launched
> discussion
>
>
> This time, I promise myself I'll write a summary of useful feedback from
everybody: I'll
> probably put in the Wiki, even if I know that such notes may not be easy
to read
>
>
> on XML vs JSON vs YAML vs ... I won't dig much for now: later
>
>
> I'd like to point to a few concrete very original topics I saw in your
examples:
>
>
> - id vs groupId + artifactId + version + ..., and even id + other field =
"overlapping fields"?:
> this could probably be applied in XML (base format independent in fact)
>
>
> - in dependencies coordinates, to classical g:a:v:t:c, you added the
dependency scope field
> (eg. provided): ouch! not convinced it is a good idea. But having
dependencies sorted by
> scope first could be interesting. Or use a different separator than :
would improve
> visibility, like g:a:v@scope, or scope|g:a:v (again base format
independent)
>
>
> These 2 aspects are interesting, IMHO, even in XML (that could be a
faster first step)
>
>
> In addition, I'd be interested in feedback on these 2 topics from people
doing tools that
> update pom.xml file:
> - maven plugins, like m-release-p or m-version-p (or ... please name
others you know)
> - IDEs
>
>
> I hope we'll manage to keep a concise useful discussion, and make some
progress on
> pom.xml maintenance
>
>
> Regards,
>
>
> Hervé
>
>
> [4] https://gnodet.github.io/maven4-presentation/[1]
>
>
> Le mercredi 5 mars 2025, 17:16:17 CET Guillaume Nodet a écrit :
> > Hey !
> >
> > A while ago, I created a Hocon based POM parser [1], leveraging Maven
> > 4 new capabilities to support new syntaxes for POMs.
> > However, as much as that syntax seems interesting, I've been pointed
> > that it's not really supported. So I never actually released it.
> > But I'd still like to get out a new syntax and so I wrote one to
> > support the well known YAML syntax. I thus created a small extension
> > to support it [2].
> > It's much more concise wrt GAV ids and especially dependencies [3].
> >
> > So I'd like to get it into the Maven project and release it.
> >
> > [1] https://github.com/apache/maven-hocon-extension
> > [2] https://github.com/gnodet/maven-yaml-extension
> > [3]
> >
https://github.com/gnodet/maven-yaml-extension/blob/master/src/test/resourc
> > es/dependency-gav.yaml#L21-L30
>
>
>
> --------
> [1] https://gnodet.github.io/maven4-presentation/
--
------------------------
Guillaume Nodet
