Yes, however that requires cooperation by the inheriting projects. The "now must override" is the challenge. It creates a burden if you want to quickly splat out a test project (which right you you can literally do with a parent pom definition, group id, artifact id and version if you are light on dependencies). In this world, for every project, even a throwaway test project, you now need to override a set of fields, otherwise the enforcer fails the build.
-h On Sun, Sep 21, 2025 at 10:53 PM <[email protected]> wrote: > Hi Henning, > > you did explain it well. In the company it is similar to e.g. an OSS > organization: > - you have a basic pom which defines e.g. a JIRA url for bugs or features > called example.com/browse/BPOM. > - same goes for project/url, which mostly points at the basic Pom's > documentation . > - all inheriting projects now must override these and so the property must > diverge. > - your proposal would set the properties to an empty state and with > enforcer you could then check whether they are set at all in inheriting > projects. > > > Best Regards > Mirko Friedenhagen > -- > Sent with my mobile > > Am 22.09.25 um 02:59 schrieb Henning Schmiedehausen > > > Ok, clearly I am not explaining this well enough. :-) > > > > I maintain a "generic base pom". I do *not* want projects using that pom > to > > inherit values from the generic pom. I accomplish this right now by > leaving > > these fields empty. So the child project *must* fill out the value. If > they > > do not fill them out, they end up with empty fields. > > > > If I were to put any information into those fields, it would bleed into > > other projects; neither would I want to be listed in the contributors > > section of the 'foo project' because they use the base pom and I added > > myself to the contributor section of the basepom nor would the owner of > the > > 'foo project' want that. > > > > Corporate poms (and the enforcer rule that you pointed out) are the > > *opposite*. You want that information everywhere to be the same and any > > project that would diverge should be flagged. > > > > My problem is that this can not be fixed from the "child" side as it > would > > require every project to cooperate which is simply impossible. This can > > only be solved from the parent side (by not filling out the fields; which > > is what I am doing right now) or the tool side (where the tool picks up > > meta-information put in by the parent and then *not* cascades down the > > values from the parent that have been marked as "do not cascade down"). > > > > I really appreciate all the suggestions, I would love to solve this > within > > the existing infrastructure but I simply can not see right now how. Which > > is why I proposed a change to the pom. > > > > -h > > > > > > On Sun, Sep 21, 2025 at 12:28 AM Mirko Friedenhagen > > <[email protected]> wrote: > > > > > Completely understandable: I maintain a company-Pom for internal > software > > > and we use the organizational URL for keeping track which team does > develop > > > the software. And teams need to specify the issue url as well in their > > > projects. > > > > > > As a workaround: extra-enforcer-rules has a rule propertyDiverges which > > > might be helpful. > > > > > > Mit freundlichen Grüßen > > > Mirko Friedenhagen > > > — > > > Sent from my mobile > > > > > > > Am 20.09.2025 um 19:53 schrieb Henning Schmiedehausen < > > > [email protected]>: > > > > > > > > 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] > > > >> > > > >> > > > > > > > > > --------------------------------------------------------------------- > > > 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] > >
