> > 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... To give you a perspective we have 9 deliverables with more that 140 artifacts. Many of those artifacts are shared at various levels between components assembled in the deliverables.
a) Well deployed snapshots generally cause more trouble than they are worth. b) I find that can be true on some days but usually find thats because the code layout is wrong or that it will stabilise after a few days c) i've made it really fast and easy to release, with ranges i pick up the next increment without having to snapshot, it means the other developer ran the tests and was confident (s)he was finished his task properly d) we must release 15 to 20 artifacts per day and at least one deliverable obviously not all of those end up in releases (murphys law the last one you build gets in) e) with snapshots I lose the control > > > 4) use version ranges to manage the contracts > I don't know much about version ranges yet. Why should I use them?! I Simple mathematical ranges i use [x,y-!) which is greater than or equal to x and less than y where y includes -SNAPSHOT, -alpha etc Without the -! the range [1,2) would match 2-SNAPSHOT or 2.0.0-SNAPSHOT which is obviously not the intention. Its simply a side effect of 2-SNAPSHOT < 2. > But then you might get a newer version, were some colleague has changed > something which might break your build. ??? indeed which is why you communicate, you have the same problem with snapshots, source depedencies etc etc. However with ranges if you do break and you don't have the time to fix it you can just do [1,1.5-!) where the version which breaks is 1.5 and now you are building until you fix your problem or push back on the other person to fix theirs... 2 seconds work... > > > > 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... we do exactly the same thing, but the view I take is what can the deliverables see... take a pragmatic approach sometime its ok to break lots of things... sometimes its not you need to make a call isolating api projects helps here as you can have many things depedent upon the api and isolate the breakages > > > 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??? I exclude dependencies that either a) should not be there which is common for ant based projects with have no transitive resolution b) i want a different version of the library which i have composed somewhere else to be consistent across all my resolution trees c) i want to get rid of the commons-logging pox, i prefer slf4j > > Are you using > dependency:analyze<http://maven.apache.org/plugins/maven-dependency-plugin/ no that was intended really to fix deps before some core changes from 2.0.5 to 2.06 or something > > > 9) set up aliases > > alias mvnsrc='mvn dependency:sources' > That must be unix / linux, I suppose. yes you can do the same with batch files on windows... best thing you could ever do > > > 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??? i have 8 parent poms - root, jar, webapp, service, model etc etc the parent pom defines distribution management, scms, and plugins for specific functions all dependencies are managed by composition not inheritance, change parents all the time sucks however with ranges and composition its easy for example for me to upgrade all the various projects to use hibernate 3.2.6ga from 3.2.5ga with one or two releases and then rebuilding the deliverables... unless of course 3.2.6ga breaks things in which case i might increment the major version of the composition... and upgrade one resolution tree at a time > > > >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! you should downgrade eclipse or patch the plugin... one key things is that when developing lots of disparate artifacts you can install the snapshot for each and the plugin will magically associate them in eclipse... that way you can have refactorings apply across all your projects at once one major GOTCHA to eclipse is that it merges the different scopes i.e. test and compile are indistiguishable, just means you should double check things on the command line... one other major GOTCHA is that eclipse and some plugin combinations on windows will lock your pom when you try to release and break the release half way through. The pain of exclusive read locks! > > :-( > : > > > regularly refactor at the artifact level not just code level > > Can you explain that in more detail? Yes you can do what i call artifactoring which bears some parallels to enterprise patterns. I am doing a presentation at the Auckland JUG in august and will post details here soon. > > > >Simple enough? > > 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 different versions, people get too hung up on artifact version but ultimately only the deliverable versions have meaning outside the dev team, just like revision numbers in source control don't matter as long as the pattern is consistent and decipherable. Ranges let you be really specific about what any project means. Using the hit and hope version def basically means you project can end up looking like anything. > 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. I would keep it simple. My motto is each artifact should build in isolation when checked out. Property interpolation from parents causes all sorts of issues. So I always have a version in an artifact, the version for the artifact is for the artifact and not for any group of projects. If you try to enforce an arbitraty version lifecycle on many artifacts in a group where do you stop? do you just have one version? I think each artifact is better served with its own... it has its own deps, its own docs, its own tests it should have its own version. This also means projects all start looking the same. my standard layout is x y z modules - which includes x, y and z as modules for testing and documentation I find with granular artifacts that the interative churn is isolated into a few artifacts at a time. Over time you can isolate the unstable artifacts, these tend to end up with large major versions ;-) Often splitting them in two reduces the churn. > > Thanks a lot, Welcome -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
