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]
