Michael McCallum wrote: > On Fri, 04 Jul 2008 02:43:03 Jörg Schaible wrote: >> Sorry, but our priority is to ensure that all artifacts are built with >> the same plugins and use the same artifact versions. In your model I have >> to duplicate all the versions for your individual service parents. That's >> what I call an anti-pattern. No, thanks, we've already bitten enough by >> that. > I do specific plugin versions strictly and dependency versions strictly > too. Its just the one is by composition and one by inheritance. > > Consider this thought experiment: > 1) push all your configuration down to the leaf poms > 2) there will be tonnes of duplication > 3) now look at the patterns of duplication > 4) you can use standard factoring techniques to take common sets of > dependencies and put them into a composition (a pom which just collects > other dependencies) (its even possible to put dependency management in > here. 5) once you have factored out all the common dependencies you will > see the the remaining patterns of configuration fall into functional > groups... one for jars, one for wars, one for ears, one for jaxb2 projects > etc etc (one could > be n). So step 5 says to pull up that configuration into common parents > by fucntion not by group. > > I guarantee that if you do this your poms will halve in size > > One of the _really_ important features of using composition whether or not > you use depMgt is that you can (with version ranges) make a change that > remains consistent across all your projects > > To prove this consider A extends P-1 and B extends P-2. P-2 changes the > version of commons collections however C depends on A and B which version > do I end up with in C? It either depends on the order of resolution of A > and B OR i can add commons collections to C as well. It becomes really > unwieldy. You need to factor and isolate, I'm sure it makes perfect sense. > Maybe I'm missing something but I've been doing this for several years and > it works.
Yep. You miss that with a global POM that defines commons-collection I do not have to declare commons-collection in C, since the depMgnt of the global parent will take precedence over any (transitive) version used originally in A or B (since M206). Note, that we use only the global POM (or project POM) to define versions in the depMgnt, deps in the modules do never ever have any own version declared (mufti order). However, the global inherited POM is necessary to lock down the versions of the plugins. This cannot be done with composition. And the usage of the same versions for plugins is essential, M2 will load every plugin only once within the same multi-project build (resulting in the unfortunate fact that you have to declare any additional dep of the antrun-plugin once alltogether). >> All kind of "individual" plugin configuration tend to be really >> "individual". As long as Maven does not support to reuse certain POM >> sections (like it is now available with scope import at least for the >> depMgmnt), you will not be able to avoid some duplication in the POMs. > the plugin configurations are merged so you can override specific > properties in the child with the 'abstract' configuration resolve from the > parent hierachy > >> >> > The overhead of putting things in the company pom is that you need to >> > change all the projects to the new version OR you can use snapshots >> > and make it a major overhead to start a release cycle >> >> It depends on your development model. We do the second and it works well. > it does and thats fair enough. But I worked on another project where they > did the same thing and said it worked well. But people still wasted half > days all the time when someone snapshot'd something that broke everything > else accidentally and there was no simple path backward. You might as well > go back to one big source tree... OK. There's one point why it might work for us better: we do not *deploy* SNAPSHOTs i.e. everyone has to build those locally. > Please take all comments with a large grain of salt. Not intending to > offend anyone, ;-) Fine with me. All I wanted was to show Peter that different strategies exist that may work out for him. One question remains: How do you lock down the dependency versions for the end product? A.jar is currently 1.1.1 B.ejb is currently 2.2.1 and depends on A[1,2-!) C.ear is currently 3.1.0 and depends on B[2,3-!) Now you deliver C.ear. You do a fix for A.jar resulting in 1.1.2. For some QA reason you will have to rebuild C-3.1.0.ear from the subversion tag ==> C-3.1.0.ear is now different - and worse, it is broken, since it contains suddenly a newer A-1.1.2.jar, while B-2.2.1.ejb still refers in the classpath of its Manifest A-1.1.1.jar. How do you address this QA problem? - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
