Message-ID: <1247636645.161.1427791084176.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_160_1028264922.1427791084175" ------=_Part_160_1028264922.1427791084175 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This is the mail of Chris:=20
I am looking for guidance on POM inheritance. I know th= at I can set up a
build system where all common functionality is pull= ed into a Parent POM, so
that Child POMs can be remarkably small. Wha= t I'm uncertain on is how I
override some of the plugins =E2=80=93 le= aving the others as is. I see that I can
override properties and cust= omize the common plugin use that way. But can I
completely override a= particular plugin?? Or perhaps add another plugin?? I
guess I'm look= ing for the rules of inheritance...
I.e can I override a plugin like this?? Is there a better way to supply<= br /> different configuration sets??=20
<configuration><= br /> <something>val2</something>
And his own follow up mail:=20
I can now answer this myself.
It appears that m2 does "the ri= ght thing" =E2=80=93 i.e. what you'd expect
All plugins are inhe= rited from the Parent. To override any Plugin, simply
declare it in t= he Child. Those you don't declare remain unchanged. All
<configura= tion> in the overriding Plugin declaration is inherited. And you
c= an override any config properties or add new ones where necessary.
Po= werful, good stuff. This, plus the ability to parameterize with
<p= roperties>, makes it really easy to create a malleable "build syste= m"
good job maven guys