Ant Best Practices: Adopt consistent style

In my first post reviewing Eric Burke’s Ant Best Practices article from 2003, we looked at putting the build file at the root of the project tree. I had a bee in my bonnet about that one; and so I skipped Eric’s first point, which is to adopt a consistent style.

The man had a point, and it’s still true. Some build files would appear to be an amalgam of different styles. Maybe I’ve been doing this too long, but I could tell who wrote certain parts of the build at my last project without looking at the version control system to find out. Just like Java code, you need to decide on tabs or spaces to indent with, and how many tabstops/spaces to set. If you’re using Eclipse, you can configure this, and check the .project file back into your project’s source repository so any Eclipse user can automatically use the same settings:


What’s changed in the intervening few years between the publication of Eric’s post and this one is just how much better IDE support for Ant has gotten. As long as you don’t do anything odd (there’s several posts in that one alone) to your build, you should be able to navigate through your build using Eclipse or IDEA. Control-clicking on a target reference will take you to that target’s definition, and you can get an outline view, amongst others. You can also run and debug the build from the IDE, which is awfully convenient.

For me, it’s a good reason not to put enormous XML comments in the build, like this:

<!– =================================
target: name
================================= –>
<target name=”name” depends=”depends” description=”–> description”>

They would be helpful if you’re editing your build.xml using a monochrome terminal and a text editor like vi (which I have done). But as IDE’s and editors get better, there’s less call for such things. I put my energies into making things consistent and easy to read. Eric: that’s 2.

Tagged

One thought on “Ant Best Practices: Adopt consistent style

  1. […] 1 of 15: Adopt consistent style 2 of 15: Put the build file at the root of your project 3 of 15: Prefer a single buildfile 4 of 15: Provide good help 5 of 15: Provide a clean target6 of 15: Manage dependencies with Ant 7 of 15: Define and reuse paths 8 of 15: Define proper target dependencies 9 of 15: Use properties for configurability 10 of 15: Keep the build process self contained 11 of 15: Use version control12 of 15: Use Ant as the least common denominator13 of 15: Use zipfileset 14 of 15: The clean test […]

Comments are closed.

%d bloggers like this: