Thanks for answering and clarify the documentation. I also looked into profiles and it looked quite promising but limitations on how they are activated and inherited let me to (yet another) dead end.
This however leaves me hung dry... how else can I obtain the desired functionality (modulate plugins behaviour for descendents with finer grain than by declaring them) Right now all I get is an all or nothing behaviour, would it be possible to use ID of some sort to determine if this or that plugin config should be used ? Here is an example to illustrate what I mean. on the four projects above C determines a base on which other projects are created. Thus I want to configure there as much of what the children behaviour as possible, simplifying as much as possible the children's creation. Now if I have different types of children on which a plugin needs to behave differently. How can I modulate this behaviour for the children right in the child POM without having to redeclare the whole plugin configuration ? Thanks Éric On Wed, Aug 12, 2009 at 11:01 PM, Brian Fox <bri...@infinity.nu> wrote: > The docs are wrong. Although it is often used for inheritence, it most > definitely applies to the current project as well. The > pluginManagement provides defaults to the plugins if they are used, > either from the cli, default lifecycle bindings, or explicit bindings > in the pom. See here for more information: > > http://www.sonatype.com/people/2008/05/optimal-maven-plugin-configuration/ > > http://www.sonatype.com/books/maven-book/reference/optimizing-sect-plugins.html > > On Wed, Aug 12, 2009 at 7:59 AM, Éric Daigneault<dai...@gmail.com> wrote: > > Hi, > > > > I was refactoring my projects to make better use of dependency management > > and pluginManagement. Almost got it all to work the way I want but I hit > a > > wall in how the pluginManagement is used. > > > > When looking at the definition in the documentation find the following > > > > *pluginManagement: is an element that is seen along side plugins. Plugin > > Management contains plugin elements in much the same way, except that > rather > > than configuring plugin information for this particular project build, it > is > > intended to configure project builds that inherit from this one. However, > > this only configures plugins that are actually referenced within the > plugins > > element in the children. The children have every right to override > > pluginManagement definitions.* > > * > > *This is all good and actually is exactly the behaviour that I am > after... > > so after hours of fiddling and looking I was quite pleased to find this > > little bit. However when actually applying I find that the plugin > > definition in plugin management are actually made active in the CURRENT > > project as well as the children. This is quite bothersome unfortunately. > > > > I created a toned downed version of my build situation to illustrate the > > issue : > > > > Project A is a generic parent POM that basically just defines the common > > parts for all projects. > > > > Project B is a library that is used in many different projects > > > > Project C is an aggregation project as well as parent POM that defines a > > framework. There is no code here, just POMs, Assembly descriptors etc. > but > > the project aggregate many projects to form a single package. I do this > to > > make it easier to develop against the framework, this way we only inherit > > from Project C and all the needed stuff is there that standardizes the > > dependencies and packaging of projects built on the framework. > > > > Project D is a project that is built on the framework, a bit of code ans > > some stuff to add to the assembly. > > > > OK... > > > > Now, everything is working well and Project C is creating a zip file as > it > > should that contains all the stuff from modules and dependencies. Now > > anyone can download the zip file and start working on the framework. Now > I > > want to define in the pluginManagement of project C some stuff to help > child > > projects to use the framework package directly instead of rebuilding it > from > > scratch everytime. Below is the POM snippet that defines this behaviour > : > > > > in Project C I have ... > > > > <build> > > <pluginManagement> > > <plugins> > > <plugin> > > <artifactId>maven-dependency-plugin</artifactId> > > <version>2.0</version> > > <executions> > > ... > > </execution> > > </executions> > > </plugin> > > </plugins> > > </pluginManagement> > > </build> > > > > if I do mvn help:effective-pom on project C I get that the build section > is > > empty, which is exactly what I ordered.. > > > > If in project D (which has project C as parent) I have the following > build > > section : > > > > <build> > > <plugins> > > <plugin> > > <artifactId>maven-dependency-plugin</artifactId> > > </plugin> > > </plugins> > > </build> > > > > > > and do a mvn help:effective-pom I get a build section that contains the > > maven-dependency-plugin with all the bells and whistle I placed in > project`s > > C pluginManagement... again all is good... > > > > But let`s say that project C wants to create something that uses > > dependencies and needs to do work with the maven-dependency-plugin. I > > therefore add the following to Project C POM : > > > > <build> > > <pluginManagement> > > <plugins> > > <plugin> > > <artifactId>maven-dependency-plugin</artifactId> > > <version>2.0</version> > > <executions> > > Some stuff for the children > > </execution> > > </executions> > > </plugin> > > </plugins> > > </pluginManagement> > > <plugins> > > <plugin> > > <artifactId>maven-dependency-plugin</artifactId> > > <version>2.0</version> > > <inherited>false</inherited> <!-- this perticular config is NOT > > for kids... for parent only --> > > <executions> > > some stuff for adults only > > </execution> > > </executions> > > </plugin> > > </plugins> > > </build> > > > > > > now if I do mvn help:effective-pom on project C I get all the stuff for > > parent AND all the stuff for kids... Thing is... I don't want the stuff > for > > kids, I am actually preparing stuff for kids.... > > > > I feel this is a bug since the documentation specifically states that the > > pluginDependencies are for decendents. Unless they are reffering to the > XML > > structure's children... in which case there is a terminology problem here > > and the documentation should probably changed to specifically state that > > children refers to the XML structure... NOT child POMs... > > > > There is a simple solution to this but it involves creating yet another > > projects, my project structure is complex enough as it stands adding > extra > > projects just to ensure maven behaves the way I want will add a lot of > > needless cruft in the project tree. Is there a way to get it to do what > I > > want without resorting to > yet-another-project-that-contains-nothing-usefull > > (codewise that is) > > > > Thanks > > > > Éric > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
