In December 2003, Eric Burke wrote a set of best practices for Ant. Given that I’ve seen some horrors in the last 4 and-a-bit years, I think it’s time to review some of them. Seeing that Ant’s cousin Nant didn’t seem to have so much market share back then, I’ll comment on that where applicable, as well. Eric’s article can still be found at O’Reilly.
Put build.xml in the Project Root Directory
If I see anther [N]Ant build with the basedir attribute set to â€œ..â€, I think I might scream. Your build file sits well at root of your project. It just works that way. If your build refers to paths, this step makes them resolvable from the build files.
â€œSo whatâ€ you might think. â€œit works, doesn’t it?â€. Yes, it might work. But this is a post about best practices. Personally, I get fed up with the doublethink required to deal with paths that are magically rooted elsewhere. Your mileage might vary.
Here’s my favourite reason for doing this: Your IDE should be able to parse your build files and have a stab at telling you if there are errors. IDEA is particularly good at this. Got no budget? Use Eclipse. On a .NET gig? Use ReSharper. Beg your boss to buy you a license after the evaluation expires. The great thing is that when you have errors in your build files (and you will), a decent IDE will try and tell you what’s going on. If you pay attention to the warnings in the build that your IDE generates, you might be able to give your build the TLC that it deserves. And your colleagues might start maintaining the build more.
For the love of God don’t make a seperate project for the build either. Try and devolve the build to the projects that use them. My verdict on this point: Eric was bang on.