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 <[email protected]> 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 <[email protected]>
> 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: [email protected]
> > 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 via email to