Better Apache Ant Builds

Abstract: We did two CITCON sessions here; Joe Schmetzer suggested a show-and-tell about tools to reduce Ant bloat, and Ivan Moore wanted a general session on improving the quality of Java builds in general. During the conference, the two sessions merged. My plan was to sit in and tweet smart-ass comments. As I had my laptop open, they made me official scribe. Serves me right. Here's my notes:

Joe: I have template Ant stuff to show you.
Ivan: I don't like Ant. Is it just me?
(someone mentions how annoying it is when you have re-entrant AntCalls)
Chris Read and Julian Simpson: "Antcall is evil! Don't use it!"
Ivan expands on his frustration with Ant: he builds something in Ant and then regrets it later. It has all the building blocks for the task at hand but he still finds it unwieldy.
Chris suggests orchestrating calls to Ant files using a scripting language.
Jeffrey Frederick suggests that writing custom Ant tasks is a good approach.

We discuss alternatives to Ant. None are found. Maven, Buildr and Gradle are mentioned but the broad agreement is that there's always a trade-of between the convenience of those tools and the flexibility of Ant. [Please direct flames to the comments of this post. I really want to discuss this more]

JTF comments that the junior guy always gets to write the build. Why does the build get treated like a second class citizen? JTF suggests PowerPoint called object oriented build scripts, and a tool called EasyAnt.

Pavel from JetBrains mentions that IntelliJ have switched to Gant, and are very happy with it. I don't believe that the all of the JetBrains Java projects have moved over.

Joe demonstrates his templates on a 9-inch netbook. This doesn't really work out as we can't get the projector going, so he outlines it. This is hard to transcribe.

Joe: Don't cut and paste Ant scripts. Import predefined targets instead. Well defined targets can be reused. This leads to tiny Ant scripts for each project. Joe's projects end up having a 10-15 lines of Ant script. Joe has released this all at Ant Script Library.

Joe explains the targets that he uses most frequently - the usual suspects of compile, test, etc. He's integrated a lot of static analysis tools into the library (he rattled off a huge list, which I failed to capture) - that's a win.

Joe's abstracted SCM and release targets nicely, by the sound of it.
Paul Duvall asks if they are targets or macrodefs. They are targets.
Joe hates code generation so doesn't use it in this toolset. Healthy discussion of script generation.
There's clear parallels with maven and the strongly defined code tree.
You can buy my refactoring ant article at at good second hand bookstores.[link]
People go against the grain of the tools.
Everyone agrees that Ant Contrib means you've done something wrong.
. JTF suggests that string literals are okay in builds.

How do you test build stuff? JTF suggests:

  • a test project
  • writing junit tests

Pavel and friends at JetBrains use personal builds to test all this.
Andy Parker asks how much container stuff and deployment you should use.
We all agree that running the production deploy in CI is the business.
Ivan: how do you deal with the devs on windows/prod on unix business
VM's are the saviour of the windows/unix divide.
The windows/unix divide is a perennial issue.
Jetbrains use build agents to try and flush out issues.

JTF: Ant builds can suck when:

  • junior people write them
  • there's no refactoring
  • they are treated as a second class citizen
  • imperative vs declarative
  • code ownership: if you touch it, you own it. Hence, nobody will touch it.

We had a vigourous discussion of dependency management. Chris asks for discipline. Andy points out that you can end up with integration hell. Maven's release plugin can allegedly resolve dependencies too late in the QA process and end up changing the release candidate. Chris complains that it can be hard to rebuild later when you depend on the latest version of a dependency. Joe did his own wrote-up here.

PS: I'll add some links back to the various people mentioned here

DevOps New Zealand