Ant Best Practices: Prefer a single buildfile

This is the third post in my series about Eric M Burke’s Top 15 Ant Best Practices from December 2003. Today’s practice is “Prefer a single buildfile”. To paraphrase Eric, it’s easier to understand a single file rather than a clever hierarchy of files. Having presided over several multi-file builds, I’m only too aware that you can easily hang yourself. On the other hand, sometimes it makes sense to extract something to a different file to achieve a separation of concerns.

If you are trying to map complex dependencies across many build files, or do amazing things in Ant or Nant, then perhaps you need to try and simplify things in your project. I once worked on a project where the frontend was written by my team, and the backend by other. The frontend team branched the work of the backend team, and the backend team kept on trucking with their work. I came to the belated conclusion that we had fallen prey to Conway’s Law; really we had one project, and we should have written it like that. The build on that project was a nightmare: two projects pretending they were free agents, but in reality hopelessly dependent on each other.

I’m torn on this practice, but I’m going to agree with Eric. Ideally you shouldn’t need multiple files. Though it does keep me in a job.

Tagged

3 thoughts on “Ant Best Practices: Prefer a single buildfile

  1. Michael Kloss says:

    I really made the same experience. Having multiple build files a couple of years ago, I now prefer more single build files. But I have noticed that a my preference started by having ant macros in place. So it is very easy to have short and clean single build files and macros doing most of the magic part. Just as you often tried to solve with multiple build files. Ok, macros could be seen also as build file but much more easier to maintain in my opinion because these are more general. My five cents, Michael

  2. […] find out. 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 target 6 of 15: Manage dependencies with Ant 7 […]

  3. Steve Newson says:

    I have to say that I think there’s a place for multi file builds. In many places I’ve worked, the build scripts have become unwieldy and complicated. Often they end up with tens of targets used for varying purposes. When I joined my current workplace, the core build script was 1500 lines long. Some attempt had been made to modularise it, but that resulted in a tangled web of XML files with antcalls back into other scripts.

    If we moved all the build scripts into a single script then we’d end up with a many thousand line script. I don’t believe that this would be any more readable than the split structure (although we would have eliminated the abysmal antcalls).

    I think there’s place here for some separation of concerns in ANT scripts (possibly encapsulation behaviour). You really want your top level build.xml to express the targets and the general flow of the build. I should be able to read the build.xml and say “The targets for this build are X, Y and Z”, “Z depends on X, and Y depends on X”, “When X runs it will compile the source code and test code”, “When Y runs it will assemble the build”. By wrapping the behaviour in well-named macros you’ll get a clear overview of how the build performs. If you want to get a better understanding of how each works, then you can delve into the core code.

    I’d argue that all the supporting code should be shifted out to an imported script. Just keep the top-level simple.

    It should also be noted that I’m using the Community Edition of IntelliJ at that has excellent support for Ant (ctrl-click through to definitions even if they are in imported files). That means that there is little or no benefit from the IDE perspective of keeping everything in one file.

Comments are closed.

%d bloggers like this: