There is definitely a desire to allow inheritence of some of the
"active" portions of the POM: plugin definitions, report definitions and
default goal. This has to be weighed up against the possiblity of this
doing something unexpected in an multi-module scenario - eg the
inclusion of a "dashboard" report at the top level that you don't want
Here is the plan as I see it, feedback welcome:
- default goal is inherited. This shouldn't harmful, and it can just be
redefined in each subproject or an intermediate ancestor (think
maven-plugins) if necessary.
- each mojo can declare whether it should be inherited by default. The
default is that it is inherited, but "@inherited false" would make the
default not to inherit. This is useful for mojos where inheritence
rarely makes sense (eg, assembly:assembly, or a dashbaord report).
- the inheritence of a mojo can be overridden by
<inherit>true|false</inherit> in the parent POM, under either goal or plugin
- note that because the inheritence default is specified at the mojo
level, plugins are always inherited so the lifecycle bindings will take
effect - so its important for mojos binding to the lifecycle that
shouldn't be inherited declare this.
- plugin and report lists are merged when inheritence, not overridden.
This means the inheritence responsibility is in the parent. There is no
way to block it out from a single pom.
I think this works in all the scenarios brought forward so far, gives
sensible defaults and reduces the amount of duplication. It also brings
the behaviour inline with dependencies.
It doesn't affect the behaviour of pluginManagement, which is always
inherited as a merge, but only applied when a plugin is made active by
being in the plugin section, or introduced through the lifecycle.