Think you didn't move to extensions, in the extension you do validate the values are there, no need of any placeholder and being neat you dump exactly the xml to write when not present doing a global "diff" and dump. No need of marker.
You wouldn't get anything better with required attributes (which BTW would be required tags in another namespace to be validated properly at xml level so likely worse for you). 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 mar. 23 sept. 2025 à 07:11, Henning Schmiedehausen <[email protected]> a écrit : > 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] > > > > >
