Re: Best practices for corporate poms

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: users@

RE: Best practices for corporate poms

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: users@maven.apache.org Subject: Best practices for corporate poms Hello, I

Re: Best practices for corporate poms

I've set some default plugins configuration (source encoding for example), fix plugin default versions, attach enforcer plugin to the build process, set the defaut reporting plugins, some profiles to help configure eclipse ... see http://repo1.maven.org/maven2/com/capgemini/platina/platina/4/plati

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