-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alright, this is the part where I print a complete retraction of everything I just emailed to the list... :)
Next time, I promise, I'll actually re-read the code and/or do some Right-Click -> References -> Project in Eclipse for a given piece of code before I shoot my mouth off. In reality, Brett is 100% correct (he should be, he's looking at the code right now :). Implied plugins like maven-compiler-plugin will also trigger the configurations in <pluginManagement/> on a plugin-by-plugin basis. So, in reality, both of the examples that I gave below will work to configure the compiler plugin. Sorry for the confusion, and I'll try not to yell my comments in from the other room next time. :) john John Casey wrote: > 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] > > > > - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFCeP/jK3h2CZwO/4URArckAJ9Lv8DBo65+87mwf6jAKtSk7acbPwCeJ6I2 H1xB7lP+X2nSRxzimJOJO24= =XWhd -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
