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]
