As this *VITAL* information flies by on the mailing list, is there anyone updating the docs.
I'd be happy to work up some of it into confluence or some such if that will help Matthew > -----Original Message----- > From: John Casey [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 27, 2005 8:14 AM > To: Maven Users List > Subject: Re: [m2] POM inheritance > > -----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]
