2008/7/3 Michael McCallum <[EMAIL PROTECTED]>: > 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 Why no snapshots?! In our company, often many people are working on the same projects, e.g. that contains shared, "common" classes - So it can happen that there will be 3 different "versions" in a single day... > > 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-!) I don't know much about version ranges yet. Why should I use them?! I Unfortunately the maven docu doesn't say may about version ranges either, but I've read this: http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution However, nothing's said about the "!" Syntax you are using. Anyway, I suppose you want to say "use a version between 1 and 2". But then you might get a newer version, were some colleague has changed something which might break your build. ??? > > when ever you make a breaking change increment the major version In our case, this is hardly ever the case. Iterative development, Little steps by steps... > > > 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-!) You mean for external dependencies, like hibernate, that do not provide a pom by themself, you create a pom yourself, I asume. Why do you exclude dependencies? I mean if some dep. has a transitive dep., it could happen that someday you will actually need this transitive dep. - and then it wouldn't hurt to have it, would it? On the other hand, having a jar that is just a bit bigger with dep. not currently used, doesn't hurt either, does it??? > 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 Are you using dependency:analyze<http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html>? I tried it, but often it declars jars as "not used but declared", but when I remove them, the project will fail at runtime or so, on the oher hand "used but not declared" often declares jars I really don't need... I don't really get it... > 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' That must be unix / linux, I suppose. > > 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 Nope, don't get it. We have all our sub projects in our parent pom. Before, we had the parent pom and a separate module pom - this makes things so much more complicated - you have to install, deploy... two poms instead of one. Also, if you just want to install, deploy... the parent pom itself without the modules, you can use the "-N" flag. Or did I miss something??? > > >use the m2eclipse plugin so that deps work properly (or equivalent plugin > for other ide of choice) Yeah, m2eclipse plugin's nice, however, it doesn't support Eclipse 3.4 yet! :-( > > > regularly refactor at the artifact level not just code level Can you explain that in more detail? > > >Simple enough? Much better, but I could stilll use some enlightment! :-) Also, I feel, even though you gave me LOTS of good tips and tweaks, you didn't really answer my question(s) - which was: 1. Use one and the same parent pom with "snapshot" as version nummer, or have different versions of the parent pom? I guess from what you wrote, different versions 2. Subprojects - version number directly in the project pom itself, or is it a good idea to have a property value for each sub project version in the parent pom, and so to keep the version in dependency management in sync with the most recent version of each current sub project version. Thanks a lot, Peter
