John has just made a final fix. So, to summarise the behaviour here: - <pluginManagement /> is inherited - <configuration/> elements are merged together during inheritence - <plugins/> is NOT inherited - the final plugin management values are merged into the <plugins/> element of the POM being built.
The downside here is that there is no way to exclude something that has already been declared in a parent. This is intended - if you come across the situation you can redefine it with a different value, or you should not inherit the value. Why was this chosen, given the downside? The downside of going the other direction (where configuration would completely replace anything given by the inherited version) was much more confusing: options set for inheritence would have disappeared from children. If anyone has any questions, please say so. J. Matthew Pryor has volunteered to help document this, so it should be available on the web site in time. Cheers, Brett On 4/28/05, Peter van de Hoef <[EMAIL PROTECTED]> wrote: > Hi John, > > I've been away for a while and see that a lot of activity has been going on > in the meantime! > Since I am just an m2 newbee, I cannot oversee if the issues arround > <plugins> and <pluginManagement> sections have been > resolved now. So I filed the <pluginManagement> issue anyway > (http://jira.codehaus.org/browse/MNG-362). Please ignore it > if it has already been fixed now. > > I will try to build the latest from SVN and perform some tests with my own > projects. > > Thanks for all the good work. > Peter van de Hoef > > John Casey wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > I'm looking at: > > > > - - org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler > > - - org.apache.maven.project.injection.DefaultModelDefaultsInjector > > > > and here's what I see: > > > > - - Combination of inherited <pluginManagement/> sections (both parent and > > child have <pluginManagement/> stuff defined): > > - ---------------------------------------------------------------------- > > > > Everything is merged, with locally specified elements overriding > > ancestor-specified elements in the event of a tie. > > > > NOTE: There was a problem with the <configuration/> of a plugin not > > being merged. I'm fixing this as we speak, although it's not going to be > > in alpha-1 obviously... :) > > > > > > > > - - Combination of local POM's <plugins/> with [inherited] > > <pluginManagement/> section: > > - ---------------------------------------------------------------------- > > > > HOW IT WORKS: <configuration/> elements (both on <goal/> and on > > <plugin/>) are combined, with ties going to the local configuration (if > > the elements collide, the local specification wins). The list of goals > > is accumulated, with the previous note applying to collisions of goals. > > That is, if the <pluginManagement/> section specifies some goals and > > their configuration for a given plugin, and the <plugin/> section > > specifies some goals, the goal definitions from the <pluginManagement/> > > section are merged into the one from the plugin specification itself. > > > > NOTE-TO-SELF: Now that I look at this, it might not be a Good Thing(tm). > > For instance, how would I suppress a goal that was declared in > > <pluginManagement/> but allow other goals from that plugin to run? How > > would I suppress plugin configuration declared similarly? > > > > HOW I'M FIXING IT TO WORK: Any <configuration/> or <goals/> element > > specified within a plugin in a local POM will negate the usage of the > > corresponding element in the <pluginManagement/> section for that > > plugin. This allows users to specify local overrides without having to > > deal with the accumulation of common settings which are wrong for the > > local case but which are not overridden in the local POM. It also makes > > the override mechanism more consistent with <dependencyManagement/>. > > > > These changes will not be available to -alpha-1, obviously, but should > > work on the svn-trunk in a few minutes. > > > > > > Hope this clears things up somewhat. :) > > > > Cheers, > > > > - -john > > > > > > J. Matthew Pryor wrote: > > > >>>From the docs here > >>http://maven.apache.org/maven2/project-descriptor.html#Build about the > >><pluginManagement/> element > >> > >>Any local configuration for a given plugin will override the plugin's entire > >>definition here. > >> > >>So what constitutes 'local configuration'. If I am to reference the plugin, > >>enough to invoke the configuration supplied in a parent <pluginManagement/>, > >>how do I do that without overriding the plugin's entire definition? > >> > >>Also am I understanding correctly that <build><plugins/> setting are never > >>inherited? > >> > >>BTW I am making good progress writing all this up for the user docs. > >>Definitely need this clarification > >> > >>jmp > >> > >> > >> > >>>-----Original Message----- > >>>From: Peter van de Hoef [mailto:[EMAIL PROTECTED] > >>>Sent: Wednesday, April 27, 2005 6:32 PM > >>>To: Maven Users List > >>>Subject: Re: [m2] POM inheritance > >>> > >>>Hi John, > >>> > >>>Thanks for your help. So <pluginManagement> is used for > >>>specifying plugin versions and configuration parameters, > >>>whether they are used or not. This will be inherited by child > >>>projects. The <plugins> section is just a list of plugins > >>>that will actually be used. This list has to be repeated in a > >>>child project though, whenever a setting of build-section has > >>>to be changed. > >>> > >>>Now, I have specified a <pluginManagement> section in the > >>>parent POM, in the hope that it gets inherited by derived > >>>projects, but it does not; in the child project, the java > >>>compiler starts complaining about assertions again. > >>> > >>>The only way to solve this is to repeat myself by inserting a > >>>copy of the <pluginManagement> section of the parent into the child. > >>> > >>>If I look at 'DefaultModelInheritanceAssembler.java' it > >>>appears that the assemblePluginManagementInheritance() > >>>function correctly takes care of <pluginManagement> sections > >>>of the parent. > >>>What is going wrong here? Did I miss something in the project defs? > >>> > >>>The parent POM looks like: > >>> > >>><project> > >>> > >>> <name>Parent POM</name> > >>> > >>> <groupId>_test</groupId> > >>> <artifactId>parent</artifactId> > >>> <version>1.0</version> > >>> <packaging>pom</packaging> > >>> > >>> <modules> > >>> <module>child</module> > >>> </modules> > >>> > >>> <build> > >>> <sourceDirectory>src</sourceDirectory> > >>> > >>> <pluginManagement> > >>> <plugins> > >>> <plugin> > >>> > >>><groupId>org.apache.maven.plugins</groupId> > >>> > >>><artifactId>maven-compiler-plugin</artifactId> > >>> > >>><version>1.0-alpha-2-SNAPSHOT</version> > >>> <configuration> > >>> <source>1.5</source> > >>> <target>1.5</target> > >>> </configuration> > >>> </plugin> > >>> </plugins> > >>> </pluginManagement> > >>> > >>> <plugins> > >>> <plugin> > >>> > >>><groupId>org.apache.maven.plugins</groupId> > >>> > >>><artifactId>maven-compiler-plugin</artifactId> > >>> </plugin> > >>> </plugins> > >>> </build> > >>> > >>></project> > >>> > >>>And the child, which inherits from the parent: > >>>The <build> section is overridden with a different > >>><sourceDirectory> and, since the <plugins> of the parent gets > >>>lost, it is repeated. > >>> > >>><project> > >>> > >>> <name>Child POM</name> > >>> > >>> <groupId>_test</groupId> > >>> <artifactId>child</artifactId> > >>> <version>1.0</version> > >>> <packaging>pom</packaging> > >>> > >>> <parent> > >>> <groupId>_test</groupId> > >>> <artifactId>parent</artifactId> > >>> <version>1.0</version> > >>> </parent> > >>> > >>> <build> > >>> <sourceDirectory>src2</sourceDirectory> > >>> <plugins> > >>> <plugin> > >>> > >>><groupId>org.apache.maven.plugins</groupId> > >>> > >>><artifactId>maven-compiler-plugin</artifactId> > >>> </plugin> > >>> </plugins> > >>> </build> > >>></project> > >>> > >>>Thanks in advance, > >>>Peter van de Hoef > >>> > >>>John Casey wrote: > >>> > >> > >>Sorry, I forgot all about the design decisions surrounding > >> > >>>>this... :) > >>>> > >> > >>Actually, our original decision was to disallow inheritance of any > >>plugin configuration, since plugin configuration can (and usually > >>will) modify the build lifecycle for that project. In light > >> > >>>>of this, > >>>> > >> > >>inherited plugin configuration could lead to somewhat > >>counter-intuitive build behavior. > >> > >>We have a <pluginManagement/> section of the POM for common > >>configuration of plugins for use within a typical > >> > >>>>multiproject-style > >>>> > >> > >>setup. It would be used like this: > >> > >>parent-pom.xml > >>------------------- > >>... > >> <pluginManagement> > >> <plugins> > >> <plugin> > >> <groupId>org.apache.maven.plugin</groupId> > >> <artifactId>maven-something-plugin</artifactId> > >> <version>1.4</version> > >> <configuration> > >> <someParam>someValue</someParam> > >> </configuration> > >> </plugin> > >> </plugins> > >> </pluginManagement> > >>... > >>------------------- > >> > >>child-pom.xml > >>------------------- > >>... > >> <parent> > >> <groupId>test</groupId> <!-- Pretend that all of > >> <artifactId>test-root</artifactId> | this resolves to the > >> <version>1.0</version> | parent-pom.xml above --> > >> </parent> > >>... > >> <build> > >> <plugins> > >> <plugin> > >> <groupId>org.apache.maven.plugin</groupId> > >> > >>>><!-- groupId, > >>>> > >> > >> <artifactId>maven-something-plugin</artifactId> | > >> > >>>>artifactId > >>>> > >> > >> </plugin> | > >> > >>>>enough here. > >>>> > >> > >> --> > >> </build> > >>... > >>------------------- > >> > >>If you need to override some setting from the pluginManagement > >>section, just specify it locally; more local specification in an > >>inheritance hierarchy wins. > >> > >>Will this solve your problem? > >> > >>HTH, > >> > >>john > >> > >> > >>Peter van de Hoef wrote: > >> > >> > >> > >>>Thanks for your reply. > >>>Now I see why the complete <build> section is inherited when it is > >>>absent in the child: > >> > >>> *if* ( childBuild == *null* ) > >>> { > >>> child.setBuild( parentBuild ); > >>> } > >>> *else* > >>> { > >>> /// A lot of fields are inherited, except <plugins> > >>>/ } > >> > >>>I understand that inheriting plugins is problematic, since > >>> > >>>>Maven does > >>>> > >>> > >>>not 'know' about the plugin parameters and cannot decide their > >>>inheritance rules. > >>>Wouldn't it be possible to inherit the complete <plugins> > >>> > >>>>section if > >>>> > >>> > >>>it is not specified in the child, just like you do with <resources> > >>>and <testResources>? > >>>That seems IMHO more in line with the situation where there is no > >>><build> section at all. In that way it is possible to 'tweak' the > >>>build settings slightly without losing the major build logic. > >>>- Peter > >> > >>>Jason van Zyl wrote: > >> > >> > >> > >>>>On Tue, 2005-04-26 at 21:00 +0200, Peter van de Hoef wrote: > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>Hi all, > >> > >>>>>I have a question about which elements of the POM are > >>>> > >>>>inherited by > >>>> > >>>> > >>>>>derived POM's. > >>>>> > >>>> > >>>> > >>>>The law on inheritance resides here: > >>>> > >>>>http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven- > >>>>project/src/main/java/org/apache/maven/project/inheritance/ > >>>> > >>>>DefaultMod > >>>> > >>>>elInheritanceAssembler.java?rev=164217&sortdir=down&view=log > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>In my parent POM I have a <build> section which specifies > >>>> > >>>>the source > >>>> > >>>> > >>>>>directory and some parameters for the java compiler: > >> > >>>>> <build> > >>>>> <sourceDirectory>src</sourceDirectory> > >>>>> <plugins> > >>>>> <plugin> > >>>>> <groupId>org.apache.maven.plugins</groupId> > >>>>> <artifactId>maven-compiler-plugin</artifactId> > >>>>> <version>1.0-alpha-2-SNAPSHOT</version> > >>>>> <configuration> > >>>>> <source>1.5</source> > >>>>> <target>1.5</target> > >>>>> </configuration> > >>>>> </plugin> > >>>>> </plugins> > >>>>> </build> > >> > >>>>>In a derived POM, the source directoriy is different, so a new > >>>>><build> section is specified: > >> > >>>>> <build> > >>>>> <sourceDirectory>module/src</sourceDirectory> > >>>>> </build> > >> > >>>>>The overridden source directory is effectuated in this > >>>> > >>>>second POM, > >>>> > >>>> > >>>>>but it appears that the java compiler settings have > >>>> > >>>>disappeared (it > >>>> > >>>> > >>>>>starts e.g. complaining about JDK 1.4 features like > >>>> > >>>>assertions). If > >>>> > >>>> > >>>>>I do not specify a <build> section in the derived POM, > >>>> > >>>>the settings > >>>> > >>>> > >>>>>of the base POM are inherited. > >> > >>>>>It appears that the <build> section is (completely) > >>>> > >>>>inherited if it > >>>> > >>>> > >>>>>is not present in the derived POM, but if a <build> section is > >>>>>specified in the derived POM, everything from the base > >>>> > >>>>POM is thrown > >>>> > >>>> > >>>>>away and only the settings of the derived POM are used. > >>>>>Is this correct? > >>>>> > >>>> > >>>> > >>>>We selectively choose what to inherit and the > >>>> > >>>>configuration for the > >>>> > >>>>plug-ins are a little trickier because they free form > >>>> > >>>>configurations > >>>> > >>>>essentially. We need to do a more careful merge of the > >>>> > >>>>configurations > >>>> > >>>>but this might not work generally so if we need to allow > >>>> > >>>>the plugin > >>>> > >>>>to determine how a configuration should be inherited then we'll > >>>>probably have to come up with some way to decide this > >>>> > >>>>using notations > >>>> > >>>>we have for plugins. Anyway, I see you posted a JIRA issue > >>>> > >>>>so we'll > >>>> > >>>>take a look at it. > >>>> > >>>> > >>>> > >> > >>>------------------------------------------------------------ > >>> > >>>>--------- > >>>> > >>> > >>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > >> > > > >>>--------------------------------------------------------------------- > >>> > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > >>>--------------------------------------------------------------------- > >>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > > > > > > > > > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.2.6 (GNU/Linux) > > > > iD8DBQFCb8uDK3h2CZwO/4URApCnAKCOW/guaN62L3k3KWfu3st8Ncdy5gCfcEg+ > > TGw7IfEJNhXiUzin23vEPyA= > > =VfpF > > -----END PGP SIGNATURE----- > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
