Ant Best Practices: Keep the build process self-contained
Posted on by Julian Simpson
Welcome back to the Ant Best Practices series. All the other posts are here, if you’ve just joined us.
Today, it’s about keeping the build process self contained. What does this mean?
When you check a project out and build it for the first time, it should take a few minutes at most to build it. I have done projects where it takes a long time to get started so you can actually build the thing. Funnily enough I’m in the process of tearing out a build system that required you to pass fully qualified paths down to it, so it can find bits of itself. When no developer checks out to the same place, you can’t consistently build it (when developers do check out to the same place, you get other issues).
This need to refer to the outside means that it’s really hard for anybody to build the project. When you introduce something like an application server that is outside the project, with environment variables to locate it, then things get even more complicated. The more that you can push into your version control system, the easier it gets. That’s why you find some developers checking enormous enterprise tools into the VCS; not because they think it’s the best place to keep things, but because you can always find them from your build.
Libraries are my favorite example. You can check them into you repository. You can’t diff them of course, but you can always find them. Some people really don’t like this behavior, and point out that VCS systems are for managing source files, and not binaries. They have a point. But what is the alternative? You could build everything from source (do you run all the tests as well?). Or you could try a dependency manager like Ivy or Maven. Maven’s dependency management is available as Ant tasks, by the way.
I’m looking forward to the release of Ant that comes with Ivy. It might make it feasible to manage binary dependancies. More on that in another post.
