You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Laird Nelson <lj...@gmail.com> on 2013/11/15 01:20:19 UTC

pluginManagement questions

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

-- 
http://about.me/lairdnelson

Re: pluginManagement questions

Posted by Hervé BOUTEMY <he...@free.fr>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org