I'm struggling to come up with the best way to handle the various versions of the various different JARs we have floating around. We've recently transitioned to Ivy from a "SVN super-project" approach, where everything (3rd party dependencies, internal company projects, etc) were all in one great big project. Made things tricky, oddly enough.
Anyway, we now have the following projects company-core partner-company-core_1 partner-company-core_2 product-core client-end-product Where company-core is a very generic set of utility projects that can be shared between all projects, partner-company-core_1/2 is a set of interfaces to external companies. Some clients may use them, some clients may not. product-core is the client-agnostic code, and the client-end-product is all the client-specific code bundled up into a WAR file and actually released. It may contain any or all of the other projects. What I'm having problems with is the versioning of the first 4 libraries. Here is my process at the moment: 1 - Make a change. 2 - Whine about lack of unit tests. 3 - Compile the code and make a JAR with Ant. 4 - Publish locally with Ivy. 5 - Make and deploy the WAR. 6 - Realize it doesn't have my updated code, grumble, clear the cache and do it again. 7 - Test. Rinse and repeat above steps. The problem comes in at step 6, really. What I would like is to be able to publish a new version of the code to my local repository, with the same version number (and maybe a qualifier, like -dev), and not have to clear the cache when Ivy resolves the dependencies for my WAR. Well, that's not quite true. I'd really like to have proper unit tests, so I don't *have* to deploy it to test it. Unfortunately, that's not practically possible at the moment. Given that, what am I missing? I'm sure I'm doing something in a less-than-optimal manner (maybe I've just missed something in my ivy settings file?), but I can't see what it is. I'd really, really appreciate some advice here... There are some related problems with IvyDE (the Eclipse plug in), but I'm not sure if I should be asking those on this list? Also, the other thing I'm wondering about, is how do you folks roll your version numbers? e.g. Once you have made a release, do you manually increment the version number by one? Do you have a script that does it all for you? Again, this is something I'm not really sure how to deal with. Should I be updating the version number every time I publish to my local repository? That seems a little insane, and means I'll eventually end up with a build number like 1.1.1841, which is a little absurd, and makes them a little meaningless. Also major potential for conflicts with other developers. Should I just roll the version number every time changes I've made to it need to go to Test? That seems like the best idea, especially since the WAR that goes to Test may end up being the WAR that goes to prod... On the other hand, if I *don't* roll the version number every time we do a release to Test, then I'm going to have no idea what's in production, as there'll be different copies of the JAR with the same version number but different contents... Auditing nightmare! Finally, how do you handle things like the '-dev' qualifier? Do you create a project, start committing everything to Trunk, eventually decide to roll a release, update the revision to remove the '-dev' tag, commit, release, then roll the version number, add the '-dev' tag and commit back to trunk? It just seems like an awful lot of steps to me, and it seems like something isn't quite right... Obviously, the best solution is something only we can decide, but I am very interested in other peoples opinions on this, and you may provide a suggestion that I wouldn't have thought of. Many thanks, - Andrew Thorburn
