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]
