Hi Michael,
well it seems everybody has some different scheme that works for him/his
company.
Michael McCallum wrote:
> 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
We use always SNAPSHOT (not even a version), therefore all components can rever
the latest parent (we have a global one for our company defining all arofact
versions in the dependencyManagement).
> 2) all depedencies are always release versions
If somebody works on a component, we use SNAPSHOT-version and set this also in
the parent POM. That reflects a change in the "core" component. All artifacts
that are dependent on this should use the SNAPSHOT parent and therefore will
use automatically the latest version (well, this policy depends actually on the
project)
> 3) release often
We release in "waves". If a major component/product has to be released, we
adjust the depMgmt in the global POM with the upcoming released versions and
release the global POM (after the release the global POM is set back to
SNAPSHOT immediately). Then each of those artifacts is released also using the
version of the just released global POM:
> 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
We do not use ranges at all. Works great without.
> 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
Why's that? Also remember that version 1 is implicitly 1.0.0.0 ;-)
> 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-!)
We make these adjustments directly in the depMgmnt of the global POM.
> 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
Especially after upgrading version of 3rd party artifacts ;-)
> 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'
Hehehe, we use bash functions:
function mc() { mvn $* clean || echo -e "\a"; }
function mi() { mvn $* install || echo -e "\a"; }
function mci() { mvn $* clean install || echo -e "\a"; }
function mcmi() { mvn $* clean && mvn $* install || echo -e "\a"; }
function me() { mvn $* eclipse:eclipse || echo -e "\a"; }
function mce() { mvn $* eclipse:clean eclipse:eclipse || echo -e "\a"; }
> 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
+1
> 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.
> 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
+1
> 14) keep all artifacts granular to simplify resolution trees
> and isolate
> change
+1
> 15) use the m2eclipse plugin so that deps work properly (or
> equivalent plugin for other ide of choice)
We use the normal maven eclipse plugin to generate the projects, no need for
m2eclipse.
> 16) DONT use the same output folders for eclipse and for
> maven as eclipse
> instruments classes and it will break things
I use the same folders without problems.
> 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 ;-)
We also :)
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
