I finally got our internal source code repository and build management system in place. In the old days we used Lotus Domino to store client deliverables and code. Because it wasn’t integrated with the development tools, it wasn’t kept up-to-date and wasn’t leveraged as often as it should have been. Eventually, people began relying on their own local code archive.

With the new infrastructure in place I’m hoping we’ll see a more up-to-date and more frequently utilized repository. Plus, because we are starting to see some in-house development efforts, this kind of integrated infrastructure became critical.

We’re using Subversion for source code control and TortoiseSVN/Subclipse as source code repository clients. All of those tools are available at Tigris.org.

We’re using Anthill as the build management system. Anthill runs builds for each of the projects in Subversion on a schedule and notifies us via email if any of the builds fail.

Quick lessons learned

Setting up Subversion on Windows was quick and easy. Subversion comes with Fedora Core 3 which is what we’re running on our repository and build servers but it was a bit trickier to get the server daemon working. I didn’t work on that piece so I don’t have specifics.

Getting Subclipse to work should have been easy. For most of the developers it was. For me it was a headache. I did something I shouldn’t have (not sure exactly what) and ended up making my default Eclipse workspace unusable for Subversion-managed projects. No big deal though–I just created a separate workspace directory for those projects and it’s all good.

I made liberal use of properties in my Ant scripts. This made my build scripts portable–I use the same script on my local machine as I do on the build server but with different properties files. This also makes it easy for other developers to configure the build for their preferences without altering the build script itself. There’s a really good article on Ant best practices here for more info.

Once I got my config in place, Anthill worked great. There are several things to be aware of, though. They are covered below.

Anthill

The Anthill install was a breeze. They’ve got an example project that checks code out of their CVS repository and builds it. That was handy. The install is a matter of unzipping the dist and copying a WAR file to your app server. There were a few stumbling blocks on the config for my projects, however.

First and foremost, I wish I would not have used spaces in my Eclipse project names. Anthill definitely has trouble coping with spaces. To work around this, I escaped the spaces in the SubversionRepositoryAdapter url property, like this:

svn://some-server/some-repos-path/some-repos/trunk/Some%20Project%20Name

and mapped it to a work directory that did not contain spaces, like this:

work/some-proj-name

There is still a space-related problem when Anthill tries to label my code in Subversion. I haven’t drilled into that one yet.

Second, the Anthill user interface leaves a little to be desired. One pain point is the anthill.build.ant.params. If you want to pass in an ant property and value, that’s two params. And, you have to do an update/edit for each param. If you have a lot of params it is really tedious. (The update-sends-you-back-instead-of-leaving-you-in-edit-mode problem is pervasive in Anthill. There needs to be a “Save” button and a “Close” button or something similar).

For example, suppose you have two ant properties you want to pass in and one includes a value. Something like, “-propertyfile someprops.properties -verbose”. In the Anthill config, this is three entries. Don’t try to put them in the same entry. You have to specify “-propertyfile”, click “Update” (which closes the project), and then re-open the project. You repeat those steps for “someprops.properties” and “-verbose”.

I also noticed a bug in which if you try to save clicks by deleting an existing param and adding a new one in the same step, the index used internally in the anthill props file for your project gets screwed up.

Last, although the Anthill documentation says you do not have to modify your Ant scripts to use Anthill, you actually do have to modify them if you plan on using dependency groups. Dependency groups tell Anthill how your projects rely on each other so it can build them in the correct order. For each project in a dependency group Anthill calls a target named “dependency”. That call gives you the chance to copy the JARs other projects are depending on to the right place. I already had that handled but I still needed to use dependency groups to control the build order so I ended up adding dummy “dependency” targets in all of my build scripts. I need to do some tests to make sure that dependent projects are getting built when they need to be.