>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: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > > 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] > >> > >> > >> > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.2.6 (GNU/Linux) > > > > iD8DBQFCbr0UK3h2CZwO/4URAqFHAJ0ay0AvjZ6oniTE+FY2m+jNMqG76QCfVpxi > > LNQUjh/RIpyil4bX6nB7RhE= > > =rNwb > > -----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]
