-----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]
