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> > <groupId>org.sonatype.oss</groupId> > <artifactId>oss-parent</artifactId> > <version>7</version> > </parent> > > Looking at that pom, there is this snippet in it: > > <build> > <plugins> > <plugin> > <groupId>org.apache.maven.plugins</groupId> > <artifactId>maven-enforcer-plugin</artifactId> > <version>1.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> > <artifactId>maven-enforcer-plugin</artifactId> > <version>1.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> > <artifactId>maven-enforcer-plugin</artifactId> > <version>1.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: > > <version>12</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 <build><plugins> stanza **and** a > <build><pluginManagement> stanza, and they declare the same plugin but > different versions, then the <build><plugins><version> 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 <build><plugins> stanza > that defines a higher version. > > I hope--if I'm right--this helps others in pinning down a stable set of > plugins for use throughout your projects, and I welcome any corrections. > > Best, > Laird --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org