Message-ID: <376859896.782478.1386405002430.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_782477_1482063407.1386405002429" ------=_Part_782477_1482063407.1386405002429 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 d= efinitions and
default goal. This has to be weighed up against the po= ssiblity of this
doing something unexpected in an multi-module scenar= io - eg the
inclusion of a "dashboard" report at the top le= vel that you don't want
Here is the plan as I see it, feedback welcome:=20
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.