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