When the extension runs, the pom(s) have already been parsed (unless I misunderstood the docs here: https://maven.apache.org/guides/mini/guide-using-extensions.html. It may be possible using a core extension to actively participate in parsing the POM but that can not be configured in the pom (it would create a chicken-egg problem).
By the time my code runs, the child POMs have been created. Only thing that I can do is put some marker values in the base pom (___PUT_DESCRIPTION_HERE__) and find these field values in the child poms and remove them. This seems brittle and also pollutes these fields that are displayed by central. So a basepom would show up as a ___PUT_DESCRIPTION_HERE_ with a license of ___PUT_LICENSE_HERE___, maintained by ___PUT_MAINTAINERS_HERE___. Not really ideal. -h On Mon, Sep 22, 2025 at 2:23 AM <[email protected]> wrote: > You may include your extension in the base pom in the extensions element. > > > Best Regards > Mirko > > Am 22.09.25 um 03:08 schrieb Henning Schmiedehausen > > > Hi, > > > > Thanks for the suggestion. I did look into extensions, however it is not > > clear to me if I can enforce an extension on a child project. The problem > > is that "cooperation from the child project picking up the pom" is a very > > brittle suggestion. ("you need to add this extension to use basepom" > almost > > surely will not fly for one project or another). The point of the POMs so > > far was "ease of use", "batteries included" and "besides defining a > > parent", the poms go from "completely passive, just defining plugin > > configs" to "minimal policy settings" to "oss compatible policy". > > > > Here are things that I looked at: > > > > - leave fields empty. This worked fine until ossrh was decommissioned > > - define the various fields with default values (e.g. > > ___BASEPOM__DESCRIPTION_HERE___) and enforcer that fails the build if any > > of the fields still has this value. Extremely cumbersome, impossible for > > e.g. contributors or license, forces users to fill out e.g. description > or > > license for "throwaway five minute" projects. Currently, literally the > > minimal pom for a project is ~ six lines. > > - use an extension to enforce, similar as above but not enforcer plugin > but > > extension. > > - use an extension to control cascading values. Less intrusive to the > > previous solution, still all the problems of an extension > > - Investigate adding attributes to the parent pom <-- currently > > investigating this > > > > Open for other suggestions. Thank you all for the suggestions you gave so > > far. > > > > -h > > > > > > > > > > > > On Sun, Sep 21, 2025 at 7:53 AM Romain Manni-Bucau < > [email protected]> > > wrote: > > > > > My 2cts would be that today it is an extension concern which has all > the > > > pro to enable to fail if a requirement is missing quite easily and not > > > require all the project needs in maven core. > > > > > > Romain Manni-Bucau > > > @rmannibucau <https://x.com/rmannibucau> | .NET Blog > > > <https://dotnetbirdie.github.io/> | Blog < > https://rmannibucau.github.io/> > > > | Old > > > Blog <http://rmannibucau.wordpress.com> | Github > > > <https://github.com/rmannibucau> | LinkedIn > > > <https://www.linkedin.com/in/rmannibucau> | Book > > > < > > > > https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064 > > > > > > > Javaccino founder (Java/.NET service - contact via linkedin) > > > > > > > > > Le dim. 21 sept. 2025 à 11:28, Hervé Boutemy <[email protected]> a > > > écrit : > > > > > > > there is already a few cases where POM inheritance has been made > > > > customizable: > > > > > > > > > > > > https://maven.apache.org/ref/3.9.11/maven-model-builder/#Inheritance_Assembly > > > > > > > > my own experience on it: > > > > - not hard to implement > > > > - hard for users to discover the feature > > > > > > > > but if you want to add such an attribute on a few elements, you can > > > > propose a > > > > PR to prove that it's not an implementation issue > > > > > > > > Reagrds, > > > > > > > > Hervé > > > > > > > > Le jeudi 18 septembre 2025, 18:59:05 CEST Henning Schmiedehausen a > écrit > > > : > > > > > So as you may know, there is this whole thread going on with Brian > Fox > > > > and > > > > > Sonatype about basepom which publishes POMs where some fields that > are > > > > > considered mandatory are not filled out because projects that > inherit > > > > from > > > > > them should not be "polluted" by these values cascading down. > > > > > > > > > > The challenge for me (and I think the actual problem) is that > there is > > > > dual > > > > > use for some of these fields that are mandatory for distribution. > > > > > > > > > > E.g. "license" is used for the project license, but it also > cascaded > > > down > > > > > to child projects as the license for them. Same for description or > even > > > > the > > > > > project name. > > > > > > > > > > I was thinking about this a bit and I wonder if we can actually > solve > > > > this > > > > > (or should solve it) at the tool level. It should be possible to a > POM > > > > > author to mark fields as "non-inheritable". So I can fill them out > for > > > > > distribution but I also know that they won't "bleed" into child > > > projects > > > > > inheriting. > > > > > > > > > > E.g. adding an attribute to the pom: > > > > > > > > > > <description cascading="false">This is a description that does not > > > > cascade > > > > > to child projects</description> > > > > > > > > > > The default would be today's behavior (which is cascading down) > but a > > > pom > > > > > author could add this attribute. > > > > > > > > > > I understand that this would be difficult in the maven 3 world due > to > > > the > > > > > wide distribution of the POM model, but there may be an > opportunity to > > > > get > > > > > this into maven 4 before we finalize the first release (I think it > will > > > > be > > > > > hard after maven 4 goes GA). > > > > > > > > > > Opinions? > > > > > > > > > > -h > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
