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