Re: maven 4.0.0 new XML stuff

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: maven 4.0.0 new XML stuff

Matthieu BROUILLARD-3
> Not exactly sure what work you mean
everything related to maven-xml: Build/ConsumerPomXMLFilterxxx,
Build/ConsumerModelSourcexxxx and the transformer stuff.
Especially, when looking at classes like CiFriendlyXMLFilter, I would have
thought that such things could have been done elsewhere, working on the
object model (not on the XML stuff) especially for the BuildPom part.

> however specifically the consumer POM integrates with so many external
ecosystems
We're aligned here, this has to be stable and well defined by a schema.

Matthieu

On Thu, Dec 31, 2020 at 3:59 PM Bernd Eckenfels <[hidden email]>
wrote:

> Hello,
>
> Not exactly sure what work you mean and I fully agree that using a core
> model should still be the API for plugins and extensions to work with,
> however specifically the consumer POM integrates with so many external
> ecosystems, I would expect it to be defined in terms of XML Schema with
> explicite semantic (and the inherent compatibility with exiting POMs).
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ________________________________
> Von: Matthieu BROUILLARD <[hidden email]>
> Gesendet: Thursday, December 31, 2020 3:19:09 PM
> An: [hidden email] <[hidden email]>
> Betreff: maven 4.0.0 new XML stuff
>
> Hello all,
>
> regarding the active work occurring for maven 4.0.0 I noticed the
> introduction of a lot of new stuff around SAX parsing & filtering.
> I am wondering if that means that it was decided that the input format of
> maven projects will be XML forever meaning probably, among others, the end
> of polyglot extensions.
> Could you explain such a move (or point to rationals/documents) and why you
> did not leverage working on the in memory object model allowing
> extensions/plugins to contribute/hook in the chain of building the BuildPOM
> & ConsumePOM? In the past I really thought that this move to 'Build vs
> Consumer' POM would make clear separations between the input format of
> descriptors and the core system but I perhaps misunderstood things.
>
> Also, are there plans regarding the future of core extensions?
> With core extensions it was possible to hook into the POM model loading and
> do transformations to do dynamic changes but by working on the XML directly
> I see a shift (if not red stop) in this contribution/delegation mechanism.
>
> Thanks for your time & answers.
>
> Matthieu Brouillard
>
Reply | Threaded
Open this post in threaded view
|

Re: maven 4.0.0 new XML stuff

Matthieu BROUILLARD-3
Thanks Robert for the video link.

I fully understand the rationales behind the separation of
build/consumer pom and the video provides some insights on it and you
explain the actual implementation to introduce this change.
Still I do not fully understand why it was decided to work on top of XML by
filtering/enhancing it instead of working at the POM (in
memory datamodel) level.
With the current understanding I have, by doing this choice of working at
XML level, it looks like it was decided to bypass (if not kill) core
extensions that enhance the POM itself and not the pom.xml ; here I can
think of (but probably not limited to):
- polyglot-maven: do not use XML but other format to describe the POM
(yaml, json, kotlin, java, other XML formats, ...)
- jgitver-maven-plugin (or forks like maven-git-versioning-extension):
dynamic computation of projects version based on git history

With the introduction of core extensions, I thought it was a move to open
the internals and let externals contribute to the capabilities of maven.
With the move to a XML handling chain, I see it as a restriction/regress in
favor of core closed functionalities. An example of that is what is
provided as CIFriendly stuff, IMO it could/should have been provided by a
plugin/extension but instead it is hard written in maven core and is not
opened for external contribution (plugin/extension I mean).

Perhaps I am totally wrong but I think that maven core should define all
its expectations at an API level so that extensions/plugins could hook at
this API level. The default packaging of maven could/should provide default
implementations of those expectations (for example reading a pom.xml file
to a POM model, dumping a POM to a pom-4.0.0.xml, transforming/reducing a
POM to POM-consumer, dumping POM-consumer to pom-consumer-5.0.0.xml, ...)
and let extensions/plugins/default implementations work along the build
process with the API & POMs to provide different features and capabilities.

Matthieu

On Thu, Dec 31, 2020 at 7:01 PM Robert Scholte <[hidden email]> wrote:

> I've made a recording[1] about it, which hopefully answers most questions.
>
> Robert
>
> [1] https://youtu.be/KDAmlNKZJto
>
> On 31-12-2020 16:18:57, Matthieu Brouillard <[hidden email]>
> wrote:
> > Not exactly sure what work you mean
> everything related to maven-xml: Build/ConsumerPomXMLFilterxxx,
> Build/ConsumerModelSourcexxxx and the transformer stuff.
> Especially, when looking at classes like CiFriendlyXMLFilter, I would have
> thought that such things could have been done elsewhere, working on the
> object model (not on the XML stuff) especially for the BuildPom part.
>
> > however specifically the consumer POM integrates with so many external
> ecosystems
> We're aligned here, this has to be stable and well defined by a schema.
>
> Matthieu
>
> On Thu, Dec 31, 2020 at 3:59 PM Bernd Eckenfels
> wrote:
>
> > Hello,
> >
> > Not exactly sure what work you mean and I fully agree that using a core
> > model should still be the API for plugins and extensions to work with,
> > however specifically the consumer POM integrates with so many external
> > ecosystems, I would expect it to be defined in terms of XML Schema with
> > explicite semantic (and the inherent compatibility with exiting POMs).
> >
> > Gruss
> > Bernd
> > --
> > http://bernd.eckenfels.net
> > ________________________________
> > Von: Matthieu BROUILLARD
> > Gesendet: Thursday, December 31, 2020 3:19:09 PM
> > An: [hidden email]
> > Betreff: maven 4.0.0 new XML stuff
> >
> > Hello all,
> >
> > regarding the active work occurring for maven 4.0.0 I noticed the
> > introduction of a lot of new stuff around SAX parsing & filtering.
> > I am wondering if that means that it was decided that the input format of
> > maven projects will be XML forever meaning probably, among others, the
> end
> > of polyglot extensions.
> > Could you explain such a move (or point to rationals/documents) and why
> you
> > did not leverage working on the in memory object model allowing
> > extensions/plugins to contribute/hook in the chain of building the
> BuildPOM
> > & ConsumePOM? In the past I really thought that this move to 'Build vs
> > Consumer' POM would make clear separations between the input format of
> > descriptors and the core system but I perhaps misunderstood things.
> >
> > Also, are there plans regarding the future of core extensions?
> > With core extensions it was possible to hook into the POM model loading
> and
> > do transformations to do dynamic changes but by working on the XML
> directly
> > I see a shift (if not red stop) in this contribution/delegation
> mechanism.
> >
> > Thanks for your time & answers.
> >
> > Matthieu Brouillard
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: maven 4.0.0 new XML stuff

Matthieu BROUILLARD-3
> Created https://issues.apache.org/jira/browse/MNG-7067 to start, now we
have an umbrella let's refine the description if needed.
Excellent and thanks.

> regarding jgitver ... Do you have a stacktrace for this?
there is no error/problem because it dumps the model manually to a pom.xml
file and reattached it to projects.
When above created issue https://issues.apache.org/jira/browse/MNG-7067
will be solved there should be no need for this specific stuff anymore.