You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Gary Gregory <ga...@gmail.com> on 2021/01/01 14:14:25 UTC

Re: maven 4.0.0 new XML stuff

Great idea to record this video, TY!

I would guess that the javadoc plugin would change in the same way the
source plugin needs to change, right?

Gary

On Thu, Dec 31, 2020, 13:01 Robert Scholte <rf...@apache.org> 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 <ma...@brouillard.fr>
> 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: dev@maven.apache.org
> > 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
> >
>

Re: maven 4.0.0 new XML stuff

Posted by Robert Scholte <rf...@apache.org>.
Yes, I think so.
Per artifact, if it includes the POM, we need to decide which one to include.
It should never be the raw one (e.g. it might miss the version to its parent), most of the time the consumer POM, but sometimes the build POM.

Robert
On 1-1-2021 15:14:52, Gary Gregory <ga...@gmail.com> wrote:
Great idea to record this video, TY!

I would guess that the javadoc plugin would change in the same way the
source plugin needs to change, right?

Gary

On Thu, Dec 31, 2020, 13:01 Robert Scholte 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
> 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: dev@maven.apache.org
> > 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
> >
>