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. > > > 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... Please take all comments with a large grain of salt. Not intending to offend anyone, ;-) -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
