Say what???

Ant, as in the Java-based build tool, is finally getting on my nerves. I'm not upset with how Ant functions or performs. It does its intended job well. My problem is with the xml configuration syntax. After a while, my eyes start to bleed while trying to read xml, any xml or sgml markup and I'm getting tired of writing it. Java apps/libraries are the worst at making me write xml configuration files by hand. Though the trend now seems to be moving away from using xml for configuration, but there is still a long way to go.

Ant's xml configuration syntax is not intended for scripting build behavior. Its intent is to define an execution tree and to define tasks to perform at each execution point. Some scripting-like behavior, such as conditionals, selective execution, and macro definitions, has been bolted on and feels awkward and is sometimes extremely verbose.

Ant takes the stance that if you have complex tasks to perform, you should create a task, which is a Java class that extends the Task class. What that means to me is that I need a build script to build the complex build logic stuff that I need to run in another build script. Its the requirement of having to compile the java code before it can be used that I find cumbersome about this process. For a very long time, this was the only way (at least when talking to a Java developer).

From my experience, script-able build tools provide the flexibility that I need for complex build systems. (see Rake, Module::Build, and GNU Make - remember each have their own quirks, just like ant; use the right tool for the right job, so no bitching please)

Groovy has helped ease some of the pain. Its ant task lets you embed groovy script directly into the build xml configuration file. The groovy task gives you access to the ant properties and ant task. This is great for short snippets of logic, like programmatically setting of properties. The groovy task can also execute external groovy scripts which is nice for reusable chunks of code.

Gradle takes it a step further. Gradle is a Groovy based build tool that in addition to its own internal tasks it also utilizes Ant's API which gives you access to ant tasks and ant properties. As of this writing, version 0.80 is mostly stable, but still has some very rough edges, suffers from the JVM start up overhead as well as the Groovy overhead at each and every invocation. A shell backed by a long running daemon process could help with that. I'm hopeful that development will continue to improve the tool.

I guess that's enough venting for now. I'll continue to use ant since its the defacto standard for Java build tools. It does what it is supposed to do and I'll just have to live wit the xml configuration for a while longer.

P.S. I have used maven, but it lacks the flexibility that I need for some projects. Its just not my cup of tea.