We are in the process of migrating our organization to Maven. We are a pretty large organization, with multiple departments and quite a lot of projects (around 40 projects just in my department).
We found that for our organization, inheritance is not the best way to manage versions (<dependencyManagement/> section). So we use inheritance almost only for the build process itself (<build/>, <pluginManagemen/>, <reporting/>, ... sections). Dependencies are managed in different poms that have only a <dependencyManagement/> section. This pom is use via composition (a dependencyManagement entry with scope "import"). We do so because different people are responsible for the build process and the versioning. It also give us more flexibility because different departments have different versioning requirements. Managing dependencies via composition give us the ability to import dependencies from different poms, which is not possible with inheritance as there is no multiple inheritance in Maven. In general, we found out that inheritance is a very strong relation, that doesnt give us enough flexibility in most cases. So my advice is to use composition as much as you can and be very suspicious of inheritance ... We also found out that Maven is lacking some functionalities for large organizations with lots of different projects. For example, if we release a new version of our parent pom, we have about 40 projects to update. We had to create specialized tools to handle that case. Version range might be able to solve this issue, but it is currently not possible to use version range in the <parent/> or <dependencyManagement/> sections ... Of course, those choices are strongly related to the way we are organized, your requirements might differ ... Good luck ! 2008/7/2 <[EMAIL PROTECTED]>: > In our super pom we have the following elements: > > <prerequisites> > <maven>2.0.7</maven> > </prerequisites> > > So each developer has at least the recommended version of maven. > > Two profiles, one default on, which defines our artifactory as central and > takes care of the distribution management and one "athome" which doesn't > define our artifactory as central repository. > > Pluginmanagement section, which nails down all the versions of the plugins we > use. > > Reporting section, so the generated sites of the projects have the same > layout, same settings, etc. > > Dependencymanagement, so all the projects use the same dependendency versions. > > Hth, > > Nick Stolwijk > ~Java Developer~ > > Iprofs BV. > Claus Sluterweg 125 > 2012 WS Haarlem > www.iprofs.nl > > > > -----Original Message----- > From: Benjamin Voigt [mailto:[EMAIL PROTECTED] > Sent: Wed 7/2/2008 08:58 > To: [email protected] > Subject: Best practices for corporate poms > > Hello, > > I'd like to know the best practices for using a corporate or a > company-wide pom, e.g. what do you put in it except for > distributionManagement ? > I've read that some people don't use SNAPSHOT versions for the corporate > pom and instead only increase a single number for every new version of > the corporate pom (e.g. version 2 to 3 to 4 etc.). > Maybe those facts could be documented somewhere on the maven site (like > a how to). > > Every idea is appreciated :) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- Jabber : [EMAIL PROTECTED] Skype : Guillaume.Lederrey Projects : * http://rwanda.ledcom.ch/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
