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