Anything executed is implied. The difference is that the plugins section can actually cause a plugin to be executed, but the equivalent management section will not.
Cheers, Brett On 5/5/05, J. Matthew Pryor <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
