not exactly: the question is not about parent and childs, but about
pluginManagement injection into build plugins, which works exactly like
dependencyManagement injection into dependencies
if you define a precise version in the build plugins (or in a dependency),
dependencyManagement does not change it: defining a version is a way to
override pluginManagement.
Then the problem here is that parent pom should not have defined a version in
build/plugins: this is a good practice exactly because it causes the problem
you're facing: you cannot upgrade the version in child pluginManagement.
The parent pom should be fixed, so you can define a new version in
pluginManagement
Regards,
Hervé
notice: the reference documentation is here
[1] http://maven.apache.org/ref/3.1.1/maven-model-builder/
Le jeudi 14 novembre 2013 16:20:19 Laird Nelson a écrit :
Suppose I have a parent pom that makes use of the maven-enforcer-plugin.
As a matter of fact I do, and it's public, so you can follow along at home:
parent
groupIdorg.sonatype.oss/groupId
artifactIdoss-parent/artifactId
version7/version
/parent
Looking at that pom, there is this snippet in it:
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-enforcer-plugin/artifactId
version1.0/version
So it declares this as a plugin that it uses internally, and says it is
going to use version 1.0. I understand that.
I also understand that this plugin definition is inherited. If I do
nothing else, and make use of the maven-enforcer-plugin, and do not specify
a version, I'll get 1.0.
Suppose now *my* pom--the first generation child--wants to enforce that
throughout its world maven-enforcer-plugin version 1.3.1 should be used.
My naive assumption was, oh, that's what pluginManagement is for. So I put
this in:
build
pluginManagement
plugins
plugin
artifactIdmaven-enforcer-plugin/artifactId
version1.3.1/version
And it's my understanding that second and greater generation children will
be forced to use version 1.3.1 as a result of that. (If I have a child
that inherits from THIS pom, then he'll use version 1.3.1.)
However, I notice that while building THIS pom the oss-parent pom is still
running maven-enforcer-plugin 1.0. It runs the maven-enforcer-plugin
during the clean lifecycle, and so when I run mvn clean from my first
generation child, I get version 1.0.
This makes a certain amount of sense--my plugin management section probably
shouldn't affect what versions my parent has chosen.
On a whim, I *also* added a plugins section *in addition* to my
pluginManagement section:
build
plugins
plugin
artifactIdmaven-enforcer-plugin/artifactId
version1.3.1/version
...and ran again. This time maven-enforcer-plugin version 1.3.1 was run.
I had to digest this for a while. Obviously my pluginManagement stanza
is not in effect--we proved that already. So my first generation child pom
can cause its parent pom to use a different version of the plugin by
specifying a new version in the plugins stanza. Is that a good thing? An
expected thing?
On another whim I upped the version here to something enormous and
nonsensical to really make sure I was seeing what I was seeing:
version12/version
...and ran again. This time--with a pluginManagement section specifying
version 1.3.1 and a parent pom specifying version 1.0 and my own pom
specifying version 12--Maven tried to download version 12, which of course
as of this writing does not exist.
From all this I have gleaned the following information, and I'm hoping
someone can tell me where I'm wrong (I'm sure I'm wrong somewhere):
* pluginManagement constrains versions for children, should they happen
to make use of the plugins mentioned therein. That's all it does.
* Without children, there is no point in putting in a pluginManagement
stanza.
* pluginManagement doesn't constrain its sibling plugins stanza, nor
does it constrain anything about its parent, nor does it constrain anything
inherited from the parent.
* Specifically, if you have a buildplugins stanza **and** a
buildpluginManagement stanza, and they declare the same plugin but
different versions, then the buildpluginsversion element will trump
everything else *in that pom* (not in his children), including any plugin
declarations from the parent.
* The versions-maven-plugin's display-plugin-updates goal will tell you
that everything is up to date and fine if you have a pluginManagement
stanza and no plugins section--but as I've already written above your
first-generation child pom may end up using an older version of a plugin
anyway, because his parent might have defined it. Even though your
pluginManagement stanza declares the proper, up-to-date version, that
version may not be respected if your parent has a buildplugins stanza
that
