Tag Archives: build

Crazy fast build times (Or when 10 seconds starts to make you nervous)

An interesting article by Daniel Worthington-Bodart – Crazy fast build times (Or when 10 seconds starts to make you nervous)

Granted, not all the techniques he describes can be applied to all projects, but the most useful thing I took away from it was the performance benefit of JARing up test classes before running them to reduce I/O time. I’ve always done this as it’s what I picked up, but now I know the reason behind it.

Dependency versions and repeatable builds

I’ve often specified dependency versions dynamically for example in ivy.xml files, without the thought that without further efforts this prevents exactly repeatable builds of projects.

That “2.+” (for latest 2.x sub-revision) on a JAR dependency may well not resolve to the same revision in a few weeks when you do a build to test a bug fix.

It’s something to keep in mind given the mix of dependencies that typically end up in a project, and the possibility of bugs and changes that can be introduced in newer versions of these.

Ant build.properties hierarchies

It’s easy for build.properties files to get out of hand when multiple projects, developers, hosts and environments are involved.

It’s pretty common to use a hierarchy of build.properties files to try and minimise duplication and keep things tidy, as described by Gene Goitmer in his blog post.

In short, this takes advantage of the fact that Ant properties cannot be overridden once set.  By importing more specific (e.g. per user) properties files first, their values will remain even if the same property exists in more general (e.g. per environment) properties files.

I find that if our product involves multiple modules/projects, duplication can be avoided by having two such hierarchies – one common one, and another for each project. The common one is imported first, and contains properties such as the location of your local Apache Ivy cache.

Gene has a useful addition to my usual process, which is to have a file called “local.build.properties” for setting properties such as passwords that we want to avoid checking in. Adding it to svn:ignore ensures that it won’t be checked in accidentally.


I think that care needs to be taken with the use of overrides, particularly when using property values to detokenize configuration files. In those cases, I’ve seen setups in the past where the main properties file (“build.properties”, which is imported last) contains many properties that aren’t common for all environments, and require them to be overridden for all other environments.

I don’t think that this is a good idea, as it in effect will default any properties that you’ve forgotten to set correctly for a particular other environment. Worst case example, you could end up using the prod database with your dev build.

By not doing this, you’ll notice immediately if you’ve forgotten to set a property as your build will fail. Or if you’re using them for detokenizing some configuration files, you’ll also notice immediately when your post-detokenizing checks finds tokens in your detokenized files.