Page History

Wiki Markup
\[PROPOSAL\] Support for Relative Ordering, Replacement, and Suppression of Mojos

NOTE: See MNG-2804, MNG-2805, and MNG-2806 for JIRA issues related to this proposal.

...

These are simply the additional mojo bindings specified in ancestor POMs that
have <inherit/> set to true (which is the default setting if nothing is
specified in most cases). For each level of inheritance, the mojo bindings
that are added are appended to the list of bindings already in that particular
phase.

iii. Mojo bindings specified in the current POM

When the current POM is built, all mojos bound in the POMs ancestry are
appended to the base lifecycle mapping given by the project's packaging. After
this happens, any mojo bindings specified in the current POM are appended to
this cumulative list of phase bindings. This means that the current POM's mojo
bindings will always be inserted into the build process after the bindings
given by its packaging and ancestry.

...

Traditionally, Maven has solved this problem by binding the new mojo to an
earlier lifecycle phase. If a suitable phase didn't exist, new phases were
introduced in later releases to address the issue. This lead to a
proliferation of 'pre-*' and 'post-*' phases, with each addressing a problem
that had no good solution until the next release of Maven.

...