My use case is pretty straightforward: I am maintaining a set of POMs for others to use (https://basepom.org/). An attribute like this would allow me to fill out all those fields that are required for distribution through central, but I can mark them with 'cascade=false' so any project that uses these as base poms, will not pick up e.g. description or license by accident (because they forgot to overwrite the field).
-h On Fri, Sep 19, 2025 at 9:41 AM Benjamin Marwell <[email protected]> wrote: > While I think this idea (as a concept) might be a good thing, > the implementation would not work. > > If you have a project with sub-projects (mvn3: [sub]modules): > Then you would need to put this on ever "last" module if those could > possibly be used as a parent. > That is unlikely due to the fact that POMs are rarely at the end of a > build tree path, but still... > > Maybe someone could come up with a better idea. > I was thinking of "GAV changes", but this would break for integration > tests, which are often under a different groupId as well. > > - Ben > > On 18/09/2025 18:59, Henning Schmiedehausen wrote: > > 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] > >
