> If I can enforce using an > assembler that does not cascade the fields down without cooperation from > the child projects using the base pom
there is a unique inheritance assembler in Maven that does POM inheritance for every effective POM built in-memory : I don't get what "enforcing an assembler" means I can't imagine a Maven extension that would change the POM inheritance code Le lundi 22 septembre 2025, 03:00:32 CEST Henning Schmiedehausen a écrit : > Yes, I looked at the inheritance assembler. If I can enforce using an > assembler that does not cascade the fields down without cooperation from > the child projects using the base pom, it is a path that I would pursue. > > -h > > On Sun, Sep 21, 2025 at 2:28 AM Hervé Boutemy <[email protected]> wrote: > > 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_Assem > > bly > > > > 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]
