Apache Ant

Apache Ant je orodje za avtomatizacijo build procesov. Napisano je v jeziku Java in je tudi primarno namenjen temu jeziku. Proces opišemo v XML dialektu, kar skupaj s prej omenjenim pomeni, da je Ant prenosljivo orodje - lahko ga poganjamo v Windows in Unix sistemih. No, samo po sebi to še ni dovolj, Ant mora namreč vsebovati potrebno funkcionalnost, da zna na primer izvesti ukaz copy transparentno ne glede na spodaj "ležeči" operacijski sistem. To pomeni, da zna ustrezno pretvarjati ali pripraviti datotečne poti, ki se na Windows in Unix sistemih razlikujejo. To je samo preprost primer prenosljivosti.

Ant je nastal, ko je Sun dal svoj interni projekt v odprtokodno skupnost za nadaljni razvoj. Ta projekt se danes imenuje Apache Tomcat. Ker v odprtokodni skupnosti ljudje uporabljamo veliko različnih kombinacij strojne in programske opreme, je nastala potreba po build orodju. Tako se je rodil Ant, ki je kot samostojeni projekt izšel poleti leta 2000. Do današnjih dni je pridobil ogromno privržencev, pravzaprav je postal de-facto standard za Java aplikacije.

Ant izvršuje naloge na podlagi napisanih opravil (tasks). Tu lahko najdete spisek, ki je razdeljen po temah. Opravila pa lahko napišemo tudi sami, če ne najdemo ustreznega. Vsekakor je za majhne in srednje velike projekte Ant primerno orodje. Nanj lahko gledamo tudi kot del standardizacije delovnega okolja razvijalcev v podjetju. Seveda lahko za build sistem uporabljamo tudi IDE okolja, v katerem razvijamo, vendar je potem potrebna konsolidacija vseh vpletenih - vsi razvojniki pač ne uporabljajo iste IDE aplikacije, če v podjetju (ali skupnosti) za nepokorščino ni zagrožena smrtna kazen. Malo šale. Nekateri IDE proizvajalci so se zavedli tega problema in vgrajujejo Ant podporo kot paralelni build način.

Omeniti je potrebno tudi negativne lastnosti. Večji kot postaja projekt, teže je obvladovati špagete XML Ant skript. Build procesna navodila v XML obliki enostavno presežejo prag zmožnosti vzdrževanja. Obvladovanje napak ni izvedeno najbolje, npr. nedefinirane spremenljivke niso vzrok za napako, ampak se tiho nadomestijo z neko pred-definirano vrednostjo.

Sicer pa, najbolje da si preberete komentar avtorja samega, ki je objavljen v knjigi Pragmatic Project Automation in ga objavljam tu v celoti.

"The Creator of Ant Exorcizes One of His Demons" by James Duncan Davidson.

The first version of Ant didn t have all the angle brackets that you see sprinkled all over its build files. Instead, it used a properties file and the java.util.Properties class to define what tasks should be executed for a target. This worked really well for small projects but started breaking down rapidly as projects grew.

The reason it broke down was the way that Ant views the world: A project is a collection of targets. A target is a collection of tasks. Each task has a set of properties. This is obviously a hierarchical tree. However, property files give you only a flat name=key mapping, which doesn t fit this tree structure at all.

I wanted a hierarchical file format that would capture the way that Ant viewed the world. But I didn't want to create my own format. I wanted to use a standard one and more important I didn't want to create a full parser for my own custom format. I wanted to reuse somebody else's work. I wanted to take the easiest way possible.

At the time, XML was just breaking out onto the radar. The spec had been completed, but only recently. SAX had become a de-facto standard, but we didn't yet have JAXP. I was convinced that XML was going to be the next big thing after Java. Portable code and portable data. Two buzzphrases that go well together.

Even better, since XML viewed data as a tree structure, it seemed like a perfect fit for the kinds of things that needed to be expressed in a build file. Add in that XML was still a hand-editable text-based format, and it seemed like a marriage made in heaven. And, I didn't have to write a parser. The deal was done.

In retrospect, and many years later, XML probably wasn't as good a choice as it seemed at the time. I have now seen build files that are hundreds, and even thousands, of lines long, and, at those sizes, it turns out that XML isn't quite as friendly a format to edit as I had hoped. As well, when you mix XML and the interesting reflection-based internals of Ant that provide easy extensibility with your own tasks, you end up with an environment that gives you quite a bit of the power and flexibility of a scripting language but with a whole lot of headache in trying to express that flexibility with angle brackets.

Now, I never intended for the file format to become a scripting language. After all, my original view of Ant was that there was a declaration of some properties that described the project and that the tasks written in Java performed all the logic. The current maintainers of Ant generally share the same feelings. But when I fused XML and task reflection in Ant, I put together something that is 70 80% of a scripting environment. I just didn't recognize it at the time. To deny that people will use it as a scripting language is equivalent to asking them to pretend that sugar isn't sweet.

If I knew then what I know now, I would have tried using a real scripting language, such as JavaScript via the Rhino component or Python via JPython, with bindings to Java objects that implemented the functionality expressed in today s tasks. Then, there would be a first-class way to express logic, and we wouldn't be stuck with XML as a format that is too bulky for the way that people really want to use the tool.