Message-ID: <430666745.42258.1371708252639.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_42257_56629138.1371708252638" ------=_Part_42257_56629138.1371708252638 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
There is definitely a desire to allow inheritence of some of the=
"active" portions of the POM: plugin definitions, report definiti= ons 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:
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.