Home Home > 2009 > 02 > 16 > Why Ant Sucks (Somehow)
Sign up | Login

Deprecation notice: openSUSE Lizards user blog platform is deprecated, and will remain read only for the time being. Learn more...

Why Ant Sucks (Somehow)

February 16th, 2009 by

What is Ant?

According to Ant’s webpage:

“Ant is a Java-based build tool. In theory, it is kind of like Make, without Make’s wrinkles and with the full portability of pure Java code.”

Sounds nice, isn’t it? But XML design problems make Ant nearly unusable which this post becomes kind of a rant…

The Current Situation

It started some time ago when I tried to use Ant for building a book. So I’ve looked into the documentation and saw Ant uses XML for their build files. “Great!”, I thought, “I start my XML editor and I’m ready to go!”

A good XML user should use a Schema whenever possible. So I searched for some DTD, RNG, or W3C Schema which my XML editor can use. However, I found this notice from the FAQ (cited from this page):

An incomplete DTD can be created by the <antstructure> task – but this one has a few problems:

  • It doesn’t know about required attributes. Only manual tweaking of this file can help here.
  • It is not complete – if you add new tasks via <taskdef> it won’t know about it. See this page by Michel Casabianca for a solution to this problem. Note that the DTD you can download at this page is based on Ant 0.3.1.
  • It may even be an invalid DTD. As Ant allows tasks writers to define arbitrary elements, name collisions will happen quite frequently – if your version of Ant contains the optional <test> and <junit> tasks, there are two XML elements named test (the task and the nested child element of <junit>) with different attribute lists. This problem cannot be solved; DTDs don’t give a syntax rich enough to support this.

(Hint: The DTD is not accessible through this link anymore—it can be found in the Ant-Wiki now.)

So with a XML editor on one hand, and with no schema on the other, Ant left me in the dark.

The Problem

So why then use XML? Why not use another syntax? The reason to use XML is not only it is easy to parse its syntax, it is also for its ability to validate your XML file. I don’t know the decisions that drove the Ant team to XML. However, it seems to me, Ant uses XML only halfhearted. This wouldn’t be bad per se. The bad thing is, that it circumvents XML good practices!

So what’s exactly my problem with Ant? I have these:

  1. A XML Structure Without Schema is Useless
    Ok, to be fair, not every XML structure needs a Schema. Very easy ones does not probably need one. However, if your structure becomes a bit more complicated, it is very important to have a Schema. It is even more important when your structure are used by other people and becomes widespread. How can people know if something is wrong when there is no Schema? Impossible! They have to run Ant every time or look into the documentation.
  2. Redefining the XML Structure is Breaking XML
    The taskdef is probably one of the worst elements in Ant. I have never seen this concept in any other XML structure before. Even when you have a Schema, it circumvents the structure by introducing new elements just “accidentally”. This makes the whole concept of your validation useless.
  3. No Official Schema
    Why using such “complicated” XML when no Schema is available? This seems not very userfriendly to offer XML without an underlying fundament.
  4. Why XML?
    Although you can tell me a “fan” of XML, I don’t think it is useful in every case. There are certainly reasons why the Ant team chooses XML over another syntax. However, then it should take into account of a schema too. I’m not fully convinced of the advantages of XML as a building tool (with the lack of a good schema.)

A Possible Solution

To improve the situation for XML users, I think the following should be interesting:

  1. Provide a RELAX NG Schema (RNG)
    In my humble opinion, this is the absolute minimum to work efficiently with Ant’s XML structure. The RNG should contain the core elements of Ant’s structure. Weather the RNG is liberal enough to allow further elements from other namespaces or not, is a matter of design.
    If your XML editor does not support RNG, there should be a DTD or W3C Schema available. However, the semantic power is not always the same with these schema languages.
  2. Use The Expressive Power of RELAX NG
    Ant’s XML structure contains sometimes conditions like: “Use only one attribute from this list.” This condition can be expressed with RNG’s choice element. The advantage of this approach: your XML editor helps you in creating valid XML during your writing.
  3. Get Rid of taskdef (And The Like)
    This was not only totally unexpected, it is a nightmare for every XML editor (as described above). No Schema should be fooled with this “broken by design” method. There are other methods to introduce further elements, be it in a separate namespace or, for example, with an element usetask with an attribute name. This might be not as short as taskdef, but it is much more safer.
  4. Document The RELAX NG Schema
    With documenting I mean not only a decent HTML page, but also some helpful tips inside the RELAX NG schema too. Modern XML editors which support annotations, can show a small tool tip to provide  users with helpful information. This is very useful as the user does not have to find the information-the information comes automatically through the XML editor.
    Another advantage: You can extract the annotation to create a separate HTML page, for example.
  5. Provide a Conversation Tool
    You can only make these “radical” steps, when there is a good conversion tool from major version n to n+1 available. This could be a XSLT stylesheet that converts the taskdef into something more useful.
  6. Offer a “Compact Syntax
    RELAX NG schemas can be written in two forms: as XML and as a compact syntax. This is very, very useful, as it allows users to take part when they don’t like XML. It is also possible to convert the two without problems. If you still need the validation structure, convert it into XML, validate it and you are done.

Schema design is not as easy as it looks. There are lots of problems that you only see after some time. That’s probably the reason, why the World Wide Web Consortium needs some time to declare a specification a W3C Recommendation.

XML can be good. But it can also be broken when it is badly designed.

Both comments and pings are currently closed.

7 Responses to “Why Ant Sucks (Somehow)”

  1. Gabriel

    So your are saying that ant sucks because it doesn’t have a DTD? Interesting.

    It seems you don’t have much experience using this tool. ok I agree that editing the build file with a generic xml editor could be quite painful, though most java developers for whom this tool is aimed, use eclipse to edit the build files. The eclipse ant editor make it simple (for someone that knows what is doing 😉 ).

    Sincerely, I prefer ant rather than maven.


    • Thomas Schraitle

      > It seems you don’t have much experience using this tool.

      That could be the case, I wouldn’t deny it. 🙂 I’ve just looked from the XML perspective.

      > […] most java developers for whom this tool is aimed, use eclipse to edit the build files.

      I haven’t tried Eclipse yet but I guess, it is rather good for this task. However, I believe, XML shouldn’t be depend on a certain tool. XML is a platform and application neutral format. If it doesn’t allow me to edit my file in any decent XML editor, than something is really fishy. 😉

  2. Josef Reidinger

    Could I ask what xml editor you use in linux? I still finding one which fulfill my requirements.

    • Sure. 🙂 The situation of XML editors in the open source field is rather bleak. Of course, there are some like Emacs, but unfortunately nothing comes close to oXygen. I use oXygen as my daily XML editor now, as it supports RELAX NG, W3C Schema, DTDs, has an XSLT debugger, and lots of other nice things.

  3. Michal Vyskocil

    Author of ant wrote some notices about ant and XML: ant dot-Next. But Java folks usually love XML, so I don’t expect that a new build system based on jython (or groovy, jruby, …) would be succesfull. And the number of Java developers which uses a generic text editor (or a generic XML one) for build.xml is futile.

    BTW: look at the maven.apache.org. This tool is much more “intelligent” and not straightforward as a simple ant, but maven POM’s files has an appropriate XML schema. I’m working on build of maven package from jpackage.org for SUSE, but it’s little bit complicated due a “dependency hell”, because maven need several new packages, which needs another packages, which needs, … and sometimes I got a circular dependency, so it consumes a lot of time 🙂

    • Thanks for your recommendation. I’ve heard about Maven but I haven’t had the time to have a closer look.

      > I’m working on build of maven package from jpackage.org for SUSE, but it’s little bit complicated due a “dependency hell”,

      Yes, Java packages can be a nightmare. I have seen Maven packages on the openSUSE buildserver:

      $ webpin --url maven
      7 results (6 packages) found for "maven" in openSUSE_110
      * maven: Maven is a software project management and comprehension tool.
      - 2.0.8 [BS::home:/eggeral]
      @ http://download.opensuse.org/repositories/home:/eggeral/openSUSE_11.0
      - 2.0.9 [BS::home:/octo47:/java]
      @ http://download.opensuse.org/repositories/home:/octo47:/java/openSUSE_11.0