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 <[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 > > >
