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]
