This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Child pages
  • Plugin and Report Inheritence

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

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:

  1. 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.
  2. 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).
  3. the inheritence of a mojo can be overridden by
    <inherit>true|false</inherit> in the parent POM, under either goal or plugin
  4. 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.
  5. 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.