-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'll try to put together a test and fix whatever's causing this. Hate to
say this again, but would you mind submitting a JIRA issue for it? :)
That'll remind me.
Peter van de Hoef wrote:
> 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/DefaultModelInheritanceAssembler.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]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFCb6m1K3h2CZwO/4URAj8HAKCVIyHtG5S2SabD0PjIrrlBvX7RbACeOskb
8A1WzqvWq6ScK3JMKCpr1yM=
=X3v4
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
