-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have a refinement or two to this...
Brett Porter wrote: > 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. This is critical: the <pluginManagement/> configurations are ONLY activated if you declare a corresponding <plugin/> entry in the build section's <plugins/> stanza. pluginManagement is an opt-in system; it will only affect your build if you specifically invite it in. Also, you cannot opt-in for all of the managed configuration at one go. To be clear: The only way to use the configuration declared within <pluginManagement/> section is to declare a corresponding <plugin/> entry within <build><plugins/></build>. The minimal information necessary to link a build's actual plugin to the corresponding managed plugin information is <groupId/> and <artifactId/>. This WILL NOT configure the source/target properties of the maven-compiler-plugin: <project> ... <build> <pluginManagement> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>1.0-alpha-1</version> <configuration> <source>1.5</source> <target>1.5</target> </configuration> </plugin> </plugins> </pluginManagement> </build> </project> The managed information will ONLY be used when you opt-in for that configuration by declaring the plugin for use in the build section, like so: <project> ... <build> <pluginManagement> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>1.0-alpha-1</version> <configuration> <source>1.5</source> <target>1.5</target> </configuration> </plugin> </plugins> </pluginManagement> <!-- THIS IS REQUIRED TO "OPT IN" TO THE MANAGED CONFIGURATION. --> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> </plugin> </plugins> </build> </project> Looking at this, I'm not 100% convinced that the implicit configuration of maven-compiler-plugin is not appropriate...the only question in that case is how to undo this configuration, which has the same answer as undoing any configuration element: don't put it in the shared configuration in the first place. All I'm attempting to do here is describe the way the current process functions...this may change in the future. > > 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: >> > 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] > > > > - --------------------------------------------------------------------- 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) iD8DBQFCePtoK3h2CZwO/4URAk95AJ4/goUiAN3zMnWSKbzta7T65CsyJgCZAZMB T5CKvn+aB7H3WnR35wJbJ/Q= =DiIK -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]