ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Widmer <>
Subject Re: Versioning Best Practices?
Date Tue, 24 Nov 2009 13:22:38 GMT
Andrew Thorburn wrote:
> 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

That's not all that dissimilar to what I have here.

> 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...

I think you can set your resolver checkmodified attribute for the local 
repo (or ivy.resolver.default.check.modified) to true, if dependencies 
in that resolver can change (e.g. the <info publication="<timestamp>" 
has changed in the ivy file) without changing version. That will 
hopefully fix your immediate problem.

> 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?

For 'core' components, where the versions are quite insulated from the 
end user and sales team, we use the format <subversion branch 
name>-rev.<subversion revision>. The revision is not held in the source 
ivy file, but is added to the delivered one (using pubrev and an ant 
property set by our build server, or 'dev-SNAPSHOT' if not running on 
the build server).

Some VCSes offer a similar incrementing revision number you can use to 
give you a version number, though others give you a revision hash, which 
can be problemmatic since it doesn't increment like a normal version does.

> 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.

For product releases, the build server manually increments the version. 
Product releases are manually triggered builds on the server, rather 
than continuous integration builds, so the numbers don't get too big.

I don't often do local multi-module builds, so haven't hit the problem 
you talk of.

> 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.

Yes, I don't think your local builds should be affecting other 
developers. It's probably easiest to use a fixed version for your local 
builds (e.g. dev-SNAPSHOT or similar).

> 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...

How about having a build server that handles it via ant scripts? Hudson 
looks very easy to set up, and is free, as is TeamCity Professional 
edition (I use the not free Enterprise version).

> 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...

You could keep revision information out of the source code as much as 
possible, and instead impose it using ant properties set by your build 
server or a non-source properties file (for local builds). The build 
script can of course write a version file into the build 
products/manifest so your software can query its own version.


View raw message