-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I actually am working on doco for the various management features. I
know this is vital, and it's not escaping in the confusion. The
documentation is coming, please bear with us. This is still pre-beta
software, after all...

- -john

J. Matthew Pryor wrote:
> As this *VITAL* information flies by on the mailing list, is there anyone
> updating the docs.
> 
> I'd be happy to work up some of it into confluence or some such if that will
> help
> 
> Matthew 
> 
> 
>>-----Original Message-----
>>From: John Casey [mailto:[EMAIL PROTECTED] 
>>Sent: Wednesday, April 27, 2005 8:14 AM
>>To: Maven Users List
>>Subject: Re: [m2] POM inheritance
>>
> 
> 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]



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFCbsdWK3h2CZwO/4URAuXkAJ9N7kxi7yr00kkONzZjs45gOcstjACfb/JH
76ATo/PCIvOXqZZJj8kovYA=
=J63u
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to