OK so my (hopefully) last question then is "How do I tell what the canonical list of 'Implied plugins like maven-compiler-plugin' is"?
Thanks for the clarification (of the clarification ;-) Matthew > -----Original Message----- > From: John Casey [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 05, 2005 3:01 AM > To: Maven Users List > Subject: Re: [m2] POM inheritance > > -----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.DefaultModelInheritanc > eAssembler > >>>- 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#Bui > ld 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
