Ant as a Scripting Language

Duncan, the original author of Ant, blogs about the origins of Ant and the addition of script features, primarily the if attribute on the element. Check it out and follow the links for some interesting discussions (although note that the Mike Cannon-Brookes page crashes my Mozilla).

Although misidentified by Duncan, someone does state there that “ANT is the absolute worst.”. Ant wasn’t supposed to be a scripting language but without those features, would Ant have been able to cope with the spectrum of build scenarios that it does today? Is a simple declarative build description powerful enough? I suspect it isn’t. Maybe it is and we just haven’t come across the right way to express the build complexity. The question is how to provide the power required in an elegant manner, without turning Ant into an XML scripting language?

My typical approach is to move complexity into tasks. My original contributions to Ant were tasks for building EJBs because I didn’t like how I had to build them using Ant’s build files and available task primitives. Tasks that express iteration, such as apply are also examples of successfully moving the control complexity into tasks. Yet, it seems Ant user’s don’t want to create tasks so much – they prefer to put the complexity right into their build files. What is the balance between a <doConorsPistonProjectBuild> task and a build file full of complexity?

Today we also have script-like tasks such as foreach possible (though not part of the Ant distribution), and the <script> task for embedded scriptlets. If you wish to, you can write pretty much arbitrary complex logic using Ant. I don’t encourage it.

So, the question is, how should it be done? How can the power be provided for dealing with complex build situations without ending up with a scripting language? Or, is a scripting language the real answer? How would the structure of a build then be expressed? I don’t know. I continue to dislike the addition of if and failonerror attributes to every task but I’m not sure how to meet the needs of the users who want these.

If you wanted the perfect build system today, unconstrained by compatibility, current mindset or other issues, what would it look like? Would it be like make, like Ant or something different? How would it describe a build, how would it deal with the arbitrarily complex operations that seem to be required in some builds?

Let me know what you think.

One Reply to “Ant as a Scripting Language”

  1. Declarative languages can include conditional stuff. Case in point: SQL; the WHERE clause contains the condition. Another example: Prolog, where it is the execution logic of the engine that controls which clauses run to the end, and which are backtracked.

    But some stuff , make ant look too like a script that it scares me. I too like stuff in tasks rather than clauses, though may be useful, and I did commit . Maybe the antlib stuff (I am lurking there) will make it easier to work with tasks, though I think it is more fundamental -people dont want to write new tasks if they can help it.

    The risk with extra power in Ant (Which try/catch, iteration and conditionals do) is to give build files complexity, moving away from the reusability of ant tasks. This worries me. But I do like try/catch, at least for deployment.

Comments are closed.