Michael McCallum wrote: > On Thu, 03 Jul 2008 19:30:58 Jörg Schaible wrote: >>> 12) set up parents that define plugins for particular types of >>> projects i.e. webapps, jars, parents, >> >> We setup the common settings in the pluginMgmnt of the global POM >> ... and lock down the plugin versions. > not quite what i was getting at, my point was that plugin > configurations tend to be common across function not group > > a common anti pattern in poms is to have > > company.pom > -> group.pom > -> model > -> service > -> war > > http://www.codinghorror.com/blog/archives/000589.html > > now repeat that pattern for 9 deliverables and you get "Duplicated > Code"
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. > the plugin configuration either goes into company.pom "Large Class" > or you have to refactor the inheritance to work by function > > company.parent > -> jar.parent > -> model.parent > > group/ > model :: model.parent > service :: service.parent > > You wil note things like this... cobertura branch/coverage > constraints are different for services and models. 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 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. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
