2009/8/13 Éric Daigneault <dai...@gmail.com>: > 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 ? >
Just override the settings you want to change in the child pom. In fact if you want a default for all children but the parent must not use the same, then you just again override in the /project/build/plugins section in the pom. /project/build/pluginManagement/plugins specifies the defaults, you can always overide an individual setting back in /project/build/plugins -Stephen > 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 >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
