Ant or Gant?

Ads by DZone

Yes, this is exactly what I am frequently asked by my clients and many developers. It isn't easy to answer this question. There are several projects using Ant. Should you run away from Ant just because there is a new cool tool out there called Gant? Should you switch to Gant just because you dislike XML? Not at all. Let's take a closer look and see what might make you switch to Gant.

When to choose Gant?

1. Complicated Build Files. If your ant build files are becoming too complicated, and hard to manage, it's time to see if using Gant can help. Let me explain what I mean by complicated build files. If you have too much of conditional logic within your build files, say something similar on the lines shown below in Listing 1:

Code Listing 1:

    <if>
      <isset property="sqlserver"/>
      <then>
        <do something here/>
      </then>
    </if>
    <if>
      <isset property="oracle"/>
      <then>
        <do something else here/>
      </then>
    </if>
    <if>
      <isset property="derby"/>
      <then>
       <do something for derby here/>
      </then>
    </if>
    <if>
      <isset property="db2"/>
      <then>
        <do something for db2 here/>
      </then>
    </if>

Or even something like this where you might be supporting deployment to different application servers based on some property in your build.properties as shown in listing 2.

Code Listing 2:

    <if>
      <isset property="server.jboss4"/>
      <then>
        <deploy to JBoss 4/>
      </then>
      <elseif>
        <isset property="server.weblogic10"/>
        <then>
	<deploy to web logic/>
        </then>
      </elseif>
      <elseif>
        <isset property="server.glassfish"/>
        <then>
          <deploy to GlassFish/>
        </then>
      </elseif>
      <elseif>
        <isset property="server.someother version"/>
        <then>
          <deploy to this some other version/>
        </then>
      </elseif>
    </if>

Things get out of hand when you have conditional logic as shown above in your build scripts. The listings I have are just the skeleton, imagine what happens when we start adding the actual deployment logic for all these application servers. It doesn't matter how you refactor this, it is still going to be very complicated. Trust me, I have written build scripts which were several thousand lines, and refactoring them was not a trivial task.

2. Custom Ant Tasks. I myself am guilty of writing many of these. There are many situations which arise in projects where we create custom ant tasks. It is simple once you know how to write one, and than for every complicated task you need to perform, you involuntarily will start writing custom ant tasks.

Anyone writing a custom ant task will:

a. Create a new class that extends Ant’s org.apache.tools.ant.Task class.

b. For each attribute, write a setter method.

c. Write an execute()method that does what you want this task to do.

There isn't anything wrong in doing the above, but imagine each time you want to make a small change, you will have to make changes within your Java source code, compile, test, and re-package.

3. Scripting. You can extend Ant further by not writing custom ant tasks, but by using small snippets of code written in an interpreted language like JRuby, BeanShell, or Groovy. These code snippets can be placed within your build files or in separate text files. If you are using Groovy's Ant task, your build file might look something like this:

Code Listing 3:

 <groovy classpathref="build.classpath">
  import some.package
  import another.package

  def fullpath = "${.basedir}/${defaulttargetdir}"

  def somefile = new SomeFile(projectName:"${pname}",
     buildLabel:"${label}", buildTime:"${new Date()}")

  def xml = "${fullpath}/dashboard.xml"

  new File(path).write(somefile.generateReport())

  ant.xslt(in:path,
    out:"${properties.defaulttargetdir}/some.html",
    style:"${properties.defaulttargetdir}/lib/report-style.xsl")
 </groovy>

Imagine having several lines of XML in your build files which have many of these small snippets of scripts. I myself don't like mixing and matching build files with code snippets. If you have a team where everyone is in the same page, everything works fine. What if a team member has no clue about any of the Scripting languages? He/She will have no clue how to make minor changes when things go badly. If you have all the above or even one of the above three cases, you seriously need to consider using Gant. To quote Aristotle:

For the things we have to learn before we can do them, we learn by doing them."

So, lets see how easy it is to learn Gant and see how things can improve.

This part covers the very basics of Gant. The next part, will dive deeper into Gant by using it with a sample project to build an application, and we will also see how to use it with our CI Server.

Subtitle:

Getting Started with Gant

Article Type:

How-to

Your rating:

Average: 3.5 (2 votes)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Thomas replied on Tue, 2008/09/23 - 6:20am

Gant goes in the right direction. But why Groovy. Why not Java?

I wrote my own pure Java build tool: PJMake (Pure Java Make). So far I use it in my own projects (the H2 Database Engine and an MP3 player).

Meera Subbarao replied on Tue, 2008/09/23 - 7:11am in response to: thomasmueller

[quote=thomasmueller]

[/quote]

I am not sure I understand your question, are you asking why Gant isn't written in Java?

Meera Subbarao

Thomas replied on Tue, 2008/09/23 - 7:44am in response to: meera

[quote=meera]are you asking why Gant isn't written in Java?[/quote]

No. My question is, why do I need to write the build definition in Groovy when using Gant? I already know Java, my application is written in Java, and don't really want to download, install and learn Groovy if I don't need to.

I know, Groovy is supposed to be more "modern". But if I want Groovy, I wouldn't write my application in Java. My IDE (Eclipse) has Java autocomplete built-in, an I am fluent in writing and debugging Java. Groovy just seems overkill for me.

David Lee replied on Tue, 2008/09/23 - 7:57am

That's a very legitimate question. But I would guess you've never really used groovy. Groovy is exactly the opposite of overkill. Once you do just a moderate amount of Groovy, I assure you, you'll be asking "why Java".

With that, I don't see much gained from going from ant to gant.

Erik Tjernlund replied on Tue, 2008/09/23 - 8:00am

I highly recommend taking a look at the build tool Schmant. Open source, powerful, easy to use and lets you use any java scripting language. Built upon the excellent java file abstraction library EntityFS.

/ET

Meera Subbarao replied on Tue, 2008/09/23 - 8:03am in response to: thomasmueller

I already know Java, my application is written in Java, and don't really want to download, install and learn Groovy if I don't need to.

That was exactly what I said until I started using Groovy. Groovy was created by Java developers who wanted writing Java code to be made simpler. Groovy reduces the amount of code you would generally write in Java. Having said all that, Groovy is Java.

Mike P(Okidoky) replied on Tue, 2008/09/23 - 12:12pm

I define my projects in a very basic xml project layout. I run that xml file through a bunch of xsl files, which generates the build.xml file.

That means I can ship my source project or check my source projects into the source repository, while no one need my xsl files, unless someone wants to regenerate the build.xml file.

Building projects and managing project files has been a breeze for years this way.

Meera Subbarao replied on Tue, 2008/09/23 - 12:23pm in response to: okidoky

[quote=okidoky]

That's something completely new to me.

Andres Almiray replied on Tue, 2008/09/23 - 1:27pm in response to: sybrix

[quote=sybrix]With that, I don't see much gained from going from ant to gant. [/quote]

If you see Gant as a way to get rid of pointy brackets, then there is surely no gain in terms of behavior. Bue when you consider that every Gant build file is also a valid Groovy script then (i.e you can embbed any valid Groovy statement) then you will probably realize why Gant is better than Ant.

How do you write conditionals in Ant? wouldn't you prefer to write them same way as you do in Java/Groovy? factor in enhanced loops, switch, closures and the Groovy Truth ... :-)

David Lee replied on Tue, 2008/09/23 - 1:50pm in response to: aalmiray

I wrote "I don't see much..." because I don't have build any outstanding Ant build problems that I haven't been able to solve without Ant's basic facilities or writing a custom task. I know Ant already, if time permits for me to play around with Gant, maybe I'll add it to my repertoire. I do have a basic problem with relearning what I already know just for the sake of it, and in this case I don't think Gant would help me with my builds.

But I'm certainly not suggesting that no one will gain from moving to Gant.

While I absolutely hate maven, I have come to acknowlegde it's excellent at solving the problem of eliminating X numbers of ways to build a war or jar, and making the build process and structure consistent. Personally, I wouldn't want to look at someone's Gant script with a bunch of conditional statements. I can easily seem them getting out of control, just because groovy is flexible like that.

Give me xml ant script or pom file any day, but preferably an ant script.

phil swenson replied on Tue, 2008/09/23 - 3:41pm in response to: sybrix

I think build.xml works ok for simple builds. But if you need to start adding any complexity, it's absolutely horrible. conditionals, debugging, iterations, custom tasks are all a huge PITA in Ant. XML was never intended for writing imperative code!

XSL to generate a build file? You are crazy.... scripting languages are perfect for this stuff. XML is purely declarative, you XML advocates are trying to put a square peg in a round hole.

I recently switched our build at work over to gant and find it much easier to work with.

If it were over again, I'd use JRuby, Rake, and the AntWrap gem instead of Groovy/Gant because Ruby is truly interpreted and I prefer Ruby to Groovy... but that being said, Gant is a fine choice.

Meera Subbarao replied on Tue, 2008/09/23 - 4:09pm in response to: philswenson

[quote=philswenson]

But if you need to start adding any complexity, it's absolutely horrible. conditionals, debugging, iterations, custom tasks are all a huge PITA in Ant.

Absolutely correct, and that's exactly when you should be using Gant as well. Good choice Phil.

Paul King replied on Tue, 2008/09/23 - 4:56pm in response to: sybrix

Re: "I do have a basic problem with relearning what I already know just for the sake of it, and in this case I don't think Gant would help me with my builds."

A nice thing about Gant is that you can leverage all of your existing Ant knowledge. The syntax has changed (improved in my eyes) but the same framework is underneath.

David Lee replied on Tue, 2008/09/23 - 5:25pm in response to: paulk_asert

Yeah, I'm aware. But I maintain my position, log4j is ok as it is for me, I could write my log4j properties files as Groovy scripts, but why ? Same goes for my ant scripts. I'm not even trying to say Gant isn't better. What I am saying is a simple ant script or log4j file is simple because they are simple. That's what people like about ant vs maven, and properties vs xml files. The simpler option is often preferred. Gant and groovy based conf files might be the best thing since slice bread, but I prefer the simpler option.

I love Groovy. Maybe I'll come around to using it everywhere, but I'm not there yet.

Serge Bureau replied on Wed, 2008/09/24 - 8:51am in response to: okidoky

I am sorry but the XSL capabilities compared to Gant are so primitive.

Plus one of the problems of build is the possibility to do sanity checking, in Gant you have access to Groovy so there is no limit to what you can do. Also you can easily automate the generation of custom built.

Build script in XML is an exersise in insanity.

In Gant all the ressources can be checked before building. What you call a breeze is not my definition at all.

Serge Bureau replied on Wed, 2008/09/24 - 8:55am in response to: philswenson

In answer to Phil,

I agree with your assesment of XML being horrible.

But as a Java programmer Groovy is the best choice, I am allergic to the syntax of Ruby .

Mike P(Okidoky) replied on Wed, 2008/09/24 - 9:32am in response to: SergeBureau

For simple projects like jar based client side application, or a war, or ear, with or without some junits, generating the build.xml from a project xml and xsl files works very well.

You simply outline what type of project it is, the library names. The rest is in the directory structure. It expects to find things in standard places, like src/jar, src/build, etc.

The libraries are searched for in the parent directories.

Although the xsl files are a bit of a b*tch to write, once things work, they don't change much over time. The project xml files are very light.

It really works quite well. Simpler and more productive than anything I've seen.

faenvie replied on Wed, 2008/09/24 - 5:24pm

gradle is another java+groovy based build-tool
IMO gradle is clearly superior to gant.
it implements support for dependency-management
and some other really smart concepts.

check it out: http://www.gradle.org

Meera Subbarao replied on Wed, 2008/09/24 - 7:25pm in response to: faenvie

[quote=faenvie]

I read the getting started guide and a few more pages. Looks very interesting. Definitely worth a try. Thanks for sharing.

Mike P(Okidoky) replied on Thu, 2008/09/25 - 7:37am in response to: faenvie

Gradle looks interesting to me too. One could create a set of company-standard project files, and get down what you have per project to a bare minimum. That's one of the key things in all my own prior build solutions. The amount of stuff you have per project. It's ok if you have a somewhat complicated build system, so long as it's there only once - and maintainable of course.

The ultimate bad solution is a honking large build.xml file per project. One step better is using include files using xml entities. The build.xml file per project suddenly goes down a lot. Another solution is using xsl files to generate build.xml, which is what I'm doing. Solutions others seem to like more is a program/script, and Groovy offers tight enough language expression where things look somewhat decent.

For now, I'll stick with my xsl solution, but for future projects, I'll definitely give gradle a shot.

Meera Subbarao replied on Thu, 2008/09/25 - 8:35am in response to: okidoky

Since we have some interest here, two to be precise on Gradle, isn't it time to write an article on Gradle? :)

Tim Boudreau replied on Fri, 2008/09/26 - 6:13pm

This looks interesting, but if you're going to have a language with branching concepts and so forth, why use XML? The example above would be much more readable without the > / and <'s.As a friend of mine put it, "XML is great for describing data, and horrible for describing behavior." I tend to agree strongly.I blogged about an interesting unfinished project to do build scripts in Java a while ago, which might be interesting if you're interested in build tools.-Tim

Mike P(Okidoky) replied on Fri, 2008/09/26 - 7:54pm in response to: tim

But a build file for a project *should* be like data. The data contains the class names and/or directories you wish to be compiled, outlines what other files to include in the jar, war, ear, etc, files.

I agree you shouldn't have things like conditional branches and programmatic type of stuff in a build file, but common simple build.xml files don't contain that. In my case, the project file that generates the build.xml through the xsl files, contains no conditional or programmy type of stuff in the project file at all.

Now the xsl is where the horror is. It's a freak show.

Perhaps gradle isn't quite *it* either. Perhaps it's better to have a project outline file where you outline the things you need and what needs to be generated, plus a template, which is the program that processes the project file. I don't like trying to be like ant using C/Java/Groovy like syntax. I think it's bad to express a target and a dependency in a Groovy program or any other program. The targets and their dependencies belong in a project file I think.

Russel Winder replied on Sat, 2008/09/27 - 2:02am

Thanks to Meera for the article, and thanks to everyone who has commented for commenting.

First let me deal with the "build specification is data" vs "build specification is program" issue. Ant XML tried to be a pure functional language so as to make build specifications declarative. This works for small projects but fails for even medium sized projects since even selection is clumsy in Ant XML. As soon as you need some form of variation in the build, Ant XML becomes awkward. Maven attempted to go to the next stage of declarative expression by applying convention over configuration and trying to remove all process from the build specification. Again for simple projects it succeeds, but for complex projects, much hacking (in the less than best sense) is needed. Experience shows us that for medium sized and large projects, the build process has to be specified with a program that has to have easy decision making. Yes things should be as declarative as possible, so avoiding explicit looping is a good guideline, but build is a process and so needs a program.

Second let me deal with the "Why Groovy not Java?" issue? I was aware of Gosling and now I see there is PJMake, there are probably others as well. There are two issues here a) the projects are not building on the Ant or Maven infrastructures and so are a revolution rather than an evolution to switch to; and b) Java is a verbose language not easily suited to creating domain specific languages (DSLs) -- not having a metaobject protocol is a barrier to some of the techniques that make writing DSLs easy and straightforward.

For good or ill Ant and Maven are the de facto standard build systems in the Java milieu. In the Ruby milieu there is Rake and in the C, C++, Fortran, and LaTeX milieux there is (the venerable) Make, (the almost mandatory) Autotools, and (the very much better than either of these) SCons. What is sadly lacking is a build system that caters for all these. C, C++ and LaTeX support in Ant and Maven is poor. Moreover C, C++ and LaTeX builds generally require more process information than Java builds.

So here is the pain: Ant has some great infrastructure but could do with more in certain areas, and XML is not the right notation for specifying process. So what is the language for writing process? In the Java milieu, the choices are Java, Groovy, Jython, JRuby, BeanShell. For me Java is too static for this task, a dynamic language is needed. For me the choice is Groovy, others have taken an alternative approach. Buildr is a Maven replacement using JRuby and Rake, Gradle is a Maven and Ant replacement written in Groovy and Java based on Ivy.

So the way of reducing the pain induced by Ant was to replace the XML processing with Groovy processing with as light a weight front end as possible. Gant is literally just a way of scripting Ant tasks with the added extra of being able to define new add-ons in Groovy.

It seems this evolution of just replacing the XML processing with Groovy processing has hit a chord. I am daily getting emails saying something along the lines of "Hey this is great, I don't need to learn a new infrastructure, but now I can express my build so much more easily." So using Groovy scripting instead of XML hacking appears to have solved a problem for many, many people.

On the question of why a dynamic language? The core issue here is the ability to synthesize dependencies. With Make you must specify explicitly all the dependencies. What SCons and then Rake brought to the game was the ability to program dependencies. This is a revolution in build specification, and one that cannot be achieved with XML without some serious hacking. Dynamic languages are thus the natural tool for specifying dependency.

So what of the future? Well Ant and Maven will continue to dominate but slowly I think Gant is expanding as Ant users see that Groovy beats XML for build specification and that they can evolve their build system bit by bit from Ant XML to Gant Groovy.

What about Gradle (and Buildr, Gosling, PJMake, etc.) well where there are new projects this is clearly an option since there is no extant build infrastructure. Where Gant wins is where there is extant build infrastructure that needs evolving. Gant is a stepping stone from Ant XML to the easier world of Groovy programming. Gant brings to the Java milieu the approach that SCons and Rake have established elsewhere. If this then leads people onto Gradle fine, but I think both Gant and Gradle will be increasingly used for different aspects of things.

Apologies for going on so long, and thanks again to Meera for the article.

Footnote: Gradle was originally going to be built on top of Gant, but Hans Dockter found he was unable to cleanly express the things he needed, so he started again from scratch. In a sense Gradle can subsume Gant since everything you can do in Gant you can do in Gradle. However I suspect the two will have take up since Gant can be sneaked in to an extant Ant build more easily than Gradle, whereas for new projects Gradle has a more "whole project management" aspect that means it is the system of choice over Maven. Gant is lightweight Ant task scripting and Groovy programming, Gradle is full on project control.

Russel Winder replied on Sat, 2008/09/27 - 2:09am

One small point on the Gant code: Ant is deprecated and ant should be used in code such as

ant.echo ( message : "hello" )

Also inside targets you don't actually need the ant. at all, you can just use echo and the Ant echo task will be called, unless you have defined a function called echo or a closure referred to by a variable called echo.

Meera Subbarao replied on Sat, 2008/09/27 - 12:04pm in response to: russel_winder

Thanks for the updates, Russel.

Serge Bureau replied on Mon, 2008/09/29 - 6:45am in response to: okidoky

Sorry but I mostly disagree.

I do not at all think a build file *should* be like data. It fact this is the problem. it is much better to be code so that it can be compiled and basic checking can go on, build files are totally unreliable, plus they are not very flexible.

I think it is perfect to use Groovy for this purpose, so not to reinvent the wheel they make it control ANT, it is brilliant.

Serge Bureau replied on Mon, 2008/09/29 - 6:50am in response to: meera

[quote=meera]Since we have some interest here, two to be precise on Gradle, isn't it time to write an article on Gradle? :)[/quote]

I am not really interested in Gradle, it depends on too many tools which makes it brittle when there will be updates of those separated tools, plus it is too complex in my opinion.

I find Gant fitting the bill much better.

Mike P(Okidoky) replied on Mon, 2008/09/29 - 5:27pm in response to: SergeBureau

I don't think you understand what my intention is.

I proposed to have all the resources and objectives placed in a project file, a data file of sorts if you will, and a script, like a template, that has all the logic to do all the work. I don't want to see java files and jar content interwoven in a script, that's all.

phil swenson replied on Mon, 2008/09/29 - 5:42pm

"I don't want to see java files and jar content interwoven in a script, that's all."

I don't see anything wrong with combining them... i suppose you could argue that if the build gets too complex then putting dependecies in a separate file might be in order.