Re: Proper Dependency Management - HowTo?

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:gholam@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...