Re: Question regarding inheritance vs pluginManagement
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 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 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 ... > > > > > > > > > > > > maven-dependency-plugin > > 2.0 > > > > ... > > > > > > > > > > > > > > > > if I do mvn help:effective-pom on project C I get that the build section > is > > e
Question regarding inheritance vs pluginManagement
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 ... maven-dependency-plugin 2.0 ... 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 : maven-dependency-plugin 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 : maven-dependency-plugin 2.0 Some stuff for the children maven-dependency-plugin 2.0 false some stuff for adults only 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
Re: POM element orders
Thanks Justin, sounds reasonable... there are so many phases to choose from I guess the expanding of the package could very well be in the pre-package phase. @Brian.. That`s just it, when I put the assembly bits in the parent POM it is systematically executed before anything in the children`s POM. I would`ve expected the opposite thereby giving children the opportunity to complete and add to the parent`s actions. Unless I did not get it right. The only way I found (without resorting to other phases) was to copy the assembly part in the children at the end of their POM. I'll give the prior phase definition a try, no reason for it not to work, though I am still puzzled by this behavior, could be a bug but I think the most likely cause is something I do not get in the maven build pattern. when you say "userbound" and "default", in the example above which is considered default ? and which is considered user bound ? also where on the net can I find a bit of help regarding all this ? I find maven really helpfull in many ways, but there is one thing I still find very hard is to reach easy to read and usefull documentation on the plugins, and on the many capabilities of Maven. It is easy inough to find trivial examples but I grew out of these quite fast. Is there anything akin to the Javadoc system that maven plungins be documented in ? Is there a repository of documenatation for plugins ? again, thanks Éric
POM element orders
Hello, I'm having a bit of a problem here ! I have a project that while not very big, does span a dependency tree a few level deep and has many leaves of final deployed packages. I use maven not only to build and all but to generate zip files that contain everything (doc, runtime environment, libraries, config files etc). This makes the job of people that have to deploy the modules a lot easier. So.. Parent POM contains all that is necessary to build the base package, most of which are set to not be inherited by the children as they will simply use the parent Zip file package as a baseline and will complete or override the necessary files to create the final packages. My problem is this, in the parent I define some build tasks that will be inherited by the children, namely : maven-compiler-plugin 1.5 1.5 true ... snip ... true maven-assembly-plugin make-assembly package attached src/main/assembly/package.xml I clipped out the extra fluff leaving the interesting bits. In the child project I have this org.apache.maven.plugins maven-dependency-plugin unpackProcessor package unpack com.purkinje ProcessorService package zip true target/processorPack false true The goal is to be able to use the definition of the parent to create a package based on the assembly rules (package.xml) that all child must have. My problem is that the assembly is executed BEFORE the unpacking and thus will not include the parent`s file as intended. The only workaround I found to this is to redefine the assembly section in each children thereby nullifying the inheritance benefit... Questions : 1 - can I control the order in which the build tasks are executed ? 2 - can I create dependencies amongst them so that the order of execution, while not controlled in absolute, would still be respected and do the intended work. 3 - is there a better way to achieve this knowing the children may very well have some code inside along with documentation and configuration ? Many thanks in advance Éric
Re: multi-module unit testing
Hi Pierre, It all depends on what you need to share. I discovered that a lot of the code I needed to share were things like data set loaders for specification tests for example. These are generic by nature and do not require any dependencies, thus making isolation in a separate module pretty straight forward. However for mocks ans stubs François's solution is more elegant where you will use the assembly plugin and generate an extra jar packaging all the test stuff together. all in all you will achieve the same end result. However you must be careful here on what you share between projects as it is generally considered bad practice for unit tests to have dependencies outside their domain. This being said recoding the same stub every time you need to fake a class from another jar is just insane, packaging mocks for the classes at the interface of the package within the same project and packaging them as separate test jars sounds much better. This is where I was coming with the solution I proposed earlier, most of my modules are split in two, one with all the interfaces, factories access and such and will becomes the API, another for the implementation. APIs can have dependencies with other APIs, Implementation will only have dependencies to it's API and other APIs. The upside is that it forces me to think long and hard about what has to be shared, what service provides the library, and how it is to be done. Natural corollary from this is that the test code that needs to be shared is quite easy to determine as other projects will have dependency only on the API. This is how I get to prevent circular dependencies since the tests will have the dame dependency graph as the rest of the project. Downside is that the project becomes very large very fast (3 to one split in modules), and this is where François's proposal becomes interesting, Under the same module project I could have it generate all three jars. Sounds a bit extreme but since I adopted this Dependencies management through dictatorship I found my advil consumption dropped dramatically, especially when the interns that work here are warned that some medival torture apparatus was rigged to their chairs and wired to the build, I then let their imaginations connect the dots if the link with anything but API packages. Anyhow, bit verbose but I hope it helped with your spinning head. ^_^. Sincerely, Éric :D. On 10/2/07, Awaragi <[EMAIL PROTECTED]> wrote: > > > Hi Eric, > > Thank you for your reply. Your solution is definitly getting me there but > I > am still a little bit confused about dependencies of these projects. > > Won't you run into a cirucular dependency issue between common test > project > and the library it support? From example, A, B are lib projects and C is > app > project, currently test setup classes are in A and B and are used by A and > B > test classes. So in theory, say you create a test project T, C will depend > on A, B and T, T depends on A and B but A and B also depend on T. Maybe I > am > thinking too much? My head is definitly hurting %-| > > Thanks again, > Pierre > > > Eric Daigneault-2 wrote: > > > > Hi Pierre, > > > > The way I solved this for myself was to create a test project and put > all > > the common test code in it (as normal stuff, not as test stuff) then I > > used > > the test project in all other projects as a dependency. This way I have > > access to the common test stuff. then to ensure that the extra project > > (jar) does not make it in the final package I declared it as test in > it`s > > dependency scope. > > > > Extending the above principle I usually have two such jars for my > > projects, > > one that is all the common code used in all tests, there I place all the > > generic stuff that can be reusable and is not specific. Another I will > > put > > all the mocks stubs and other such classes that are specific to the high > > level project. This way all modules will have access to them and I only > > code my stuff once. Great thing about this is that I can then code unit > > tests on the test classes. May sound a bit excessive but when people > > lives > > depend on the code you produce a bit of paranoia actually help to > protect > > ones sanity. > > > > Of course for the stubs parts, to prevent circular dependencies you may > > have > > to separate the interface for your library from the implementation, > which > > in > > time makes for more stable code. The downside is the multiplication of > > modules. > > > > I hope this helps > > > > Éric :D. > > > > > > On 10/1/07, Awaragi <[EMAIL PROTECTED]> wrote: > >> > >> > >> Hi All, > >> > >> i hope that this question was not asked before as I am new to maven and > >> to > >> this forum. I am trying to build a multi-module project with three > >> modules: > >> libraries A and B and application C which depends on A and B. Libraries > A > >> and B have their unit testing classes which use a setup class to load > >> testing resources,
Re: multi-module unit testing
Hi Pierre, The way I solved this for myself was to create a test project and put all the common test code in it (as normal stuff, not as test stuff) then I used the test project in all other projects as a dependency. This way I have access to the common test stuff. then to ensure that the extra project (jar) does not make it in the final package I declared it as test in it`s dependency scope. Extending the above principle I usually have two such jars for my projects, one that is all the common code used in all tests, there I place all the generic stuff that can be reusable and is not specific. Another I will put all the mocks stubs and other such classes that are specific to the high level project. This way all modules will have access to them and I only code my stuff once. Great thing about this is that I can then code unit tests on the test classes. May sound a bit excessive but when people lives depend on the code you produce a bit of paranoia actually help to protect ones sanity. Of course for the stubs parts, to prevent circular dependencies you may have to separate the interface for your library from the implementation, which in time makes for more stable code. The downside is the multiplication of modules. I hope this helps Éric :D. On 10/1/07, Awaragi <[EMAIL PROTECTED]> wrote: > > > Hi All, > > i hope that this question was not asked before as I am new to maven and to > this forum. I am trying to build a multi-module project with three > modules: > libraries A and B and application C which depends on A and B. Libraries A > and B have their unit testing classes which use a setup class to load > testing resources, setup database connection, etc. This works all fine and > nice for A and B. Now I am in the process of writting unit tests for > application module C and i don't want to do copy/paste of the setup > classes > of A and B but I cannot find a way to make unit test classes of C to > depend > on unit test classes of A and B. > > I thought of moving some of these setup classes to main as a workaround > but > then i have to add quite a few test libraries to these modules and to the > web-inf/lib folder of the final war file. Including a database jdbc driver > is not acceptable so this workaround is not the way to go. > > Can anyone please help me with this setup? > > Pierre > -- > View this message in context: > http://www.nabble.com/multi-module-unit-testing-tf4551612s177.html#a12989166 > Sent from the Maven - Users mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: custom jar contents?
Simple answer : If you need two jars then your project needs to be broken into two separate projects. To get a better understanding I would like to know why you require to have two jars ? different configurations ? optional components ? Believe me here I got through this a while ago on Maven and the best answer I found was to rethink long and hard as to why I needed this done, and the answer was that, in all things were made a lot simpler if I simple split the project in two separate jars then have a top level project to generate the actual package. Sometimes this top level package does not contain code at all, just POM and other declarations to determine the final packaging. For this I use the assembly plugin ( http://maven.apache.org/plugins/maven-assembly-plugin/) and generate a zip file with all needed for the software in a single archive. This being said... if you absolutely neeed the extra jars and spliting the code makes absolutely no sense the it is most probably possible to use the assembly plugin to bend the one project one jar rule. to summarize, at first I found Maven very frustrating to use until I found out that rethinking the way a project should be laid-out and how it should be built and packaged to follow Maven's philosophy it made things much more simple in the long run. After I changed to bend my habits to maven instead of the opposite I discovered I was spending MUCH less time managing the projects and packages and much more time actually coding and getting things done. On 10/1/07, Sonar, Nishant <[EMAIL PROTECTED]> wrote: > > Hi > > I have a structure as > > MyAppModule > > Src > > Main > > Java > > Com > > Myapp > > Bankapplication > > Some classes > > Utilities > > FormulaCalc > > someclasses > > DateCalc > > Someclasses > > Pom.xml > > > > I need top have 2 jars as utilitied and myappmodule. What can I do for > such a case where there's a single pom to generate 2 jars comprising > selective classes? > > > > -Nishant > >
