On Thu, 03 Jul 2008 00:44:20 Peter Horlock wrote: > Could you be a bit more precise? (Just make it plain simple, this increases > the chance that I get it! ;-) I suppose
The things i do 1) parent version are always release versions 2) all depedencies are always release versions 3) release often 4) use version ranges to manage the contracts e.g. project.api = 1.x project.implementation uses api.[1,2-!) project.consumer uses api.[1,2-!) project.deployable uses implementation.[1,2-!) and consumer.[1,2-!) obviously in the real world things aren't this simple and for simple cases this seems like excessive overhead 5) when ever you make a breaking change increment the major version 6) start version numbering 1.1 for new artifacts * makes ranges work better * who needs the extra .0 on the end, i save that for patches 7) in order to integrate 3p libraries i create a wrapping pom which follows the above version rules e.g. for hibernate i have hibernate.composite 7.x uses hibernate 3.2.6ga, uses ehcache 3.0, uses cglib... excludes commons-logging, excludes ehcache, excludes cglib-full and all my projects the use hibernate use hibernate.composite.[7,8-!) 8) use mvn dependency:resolve and mvn depedendency:tree regularly to understand how things are working and to catch any transitions that i did not expect 9) set up aliases alias mvnsrc='mvn dependency:sources' alias mvntag='mvn release:prepare -Penforce-no-snapshots' alias mvntree='mvn dependency:tree' alias mvnup='mvn release:perform -Dgoals=deploy' alias mvndep='mvn dependency:resolve' 10) use the enforcer to ensure releases don't contain snapshots make sure to traverse transitions 11) don't mix inheritance and aggregation. that means a parent pom NEVER ever has modules, if you think about the concept for a minute - or longer - there will be a moment of enlightenment 12) set up parents that define plugins for particular types of projects i.e. webapps, jars, parents, 13) define repositories in settings.xml, been meaning patch the settings resolver to load profiles from a directory so that i can source control the repositories for different projects independency 14) keep all artifacts granular to simplify resolution trees and isolate change 15) use the m2eclipse plugin so that deps work properly (or equivalent plugin for other ide of choice) 16) DONT use the same output folders for eclipse and for maven as eclipse instruments classes and it will break things 17) regularly refactor at the artifact level not just code level Simple enough? I might diverge from common practise in some places but I'm pretty sure from watching the lists that I have way fewer problems as a result ;-) -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
