Apache Ant

Apache Ant (Another Neat Tool)
Fejlesztő	Apache Software Foundation
Legfrissebb stabil kiadás	1.10.14 (stabil verzió, 2023. augusztus 21.)[1]
Programozási nyelv	Java
Operációs rendszer	platformfüggetlen
Platform	Java virtuális gép
Állapot	aktív
Kategória	Build Tool
Licenc	Apache Licenc 2.0
Az Apache Ant (Another Neat Tool) weboldala

Az Apache Ant olyan szoftver segédeszköz, amely szoftver projektek buildelésének automatizálására használható. Hasonló a C/C++-os világban megszokott Make eszközhöz, ám azzal ellentétben ez teljes egészében java nyelven íródott (100% Pure java), futtatásához java platform szükséges és leginkább java projektekhez buildeléséhez használatos.

A legszembetűnőbb különbség az Ant és a Make között, hogy az Ant XML-t használ a build folyamat és függőségek leírásához, míg a Make-nek megvan a saját Make-fájl formátuma. Az Ant leíró XML fájlját build.xml-nek nevezzük.

Ant az Apache Software Foundation egy projektje, amely nyílt forráskódú szoftver, és Apache Licenc alatt lett kibocsátva.

Ant-ot James Duncan Davidson kezdte el kifejleszteni, egy Sun termék nyílt forráskódúvá való átalakítása közben. A termék történetesen a Sun referencia JSP/Servlet motorja volt, mely később az Apache Tomcat néven vált ismertté. Egy szabadalmaztatott make szoftver verziójának segítségével készült a build-je Solaris operációs rendszer alatt, de a szabad szoftverek világában semmi mód nincs arra, hogy befolyásoljuk, melyik platformot választják a Tomcat build-elésére. Az Ant egy egyszerű platformfüggetlen eszköznek készült a Tomcat buildeléséhez, ahol a build-utasítások XML "buildfájl"-ban voltak definiálva. Ebből a szerény kezdetből az eszköz odáig jutott, hogy elterjedtebb lett, mint maga a Tomcat, amihez készítették. Az Antot, mint önálló terméket (1.1-es verzió), hivatalosan 2000. július 19-én bocsátották ki. Ma az Ant a legtöbb java fejlesztésnél használt buildeszköz.^[2] Pl. a legtöbb szabad forráskódú szoftver fejlesztője mellékeli a build.xml fájlját a disztribúcióihoz.

Mivel az Ant természetessé tette a JUnit tesztek beépítését a build folyamatba, így az Ant megkönnyítette a fejlesztők számára a teszt vezérelt fejlesztés valamint az extrém programozás gondolkodásmódjának elfogadását.

Léteznek más java alapú build eszköz is pl. Maven és JavaMake.^[3]

A név egy betűszó az angol "Another Neat Tool"-re.^[4]

A következő egyszerű build.xml fájl a java "Hello, world" alkalmazás buildelésére szolgál.

Négy célt (angolul target) definiál - clean, clobber, compile és jar, mindegyikhez ad leírást is. A jar cél függ a compile céltól. Arra utasítja az Ant-ot, hogy mielőtt belekezdene a jar célt végrehajtásába, először be kell fejeznie a compile cél végrehajtását.

<?xml version="1.0"?>
<project name="Hello" default="compile">
    <target name="clean" description="remove intermediate files">
        <delete dir="classes"/>
    </target>
    <target name="clobber" depends="clean" description="remove all artifact files">
        <delete file="hello.jar"/>
    </target>
    <target name="compile" description="compile the Java source code to class files">
        <mkdir dir="classes"/>
        <javac srcdir="." destdir="classes"/>
    </target>
    <target name="jar" depends="compile" description="create a Jar file for the application">
        <jar destfile="hello.jar">
            <fileset dir="classes" includes="**/*.class"/>
            <manifest>
                <attribute name="Main-Class" value="HelloProgram"/>
            </manifest>
        </jar>
    </target>
</project>

Minden célban akciók (angolul: action) vannak, amelyeket az Antnak végre kell hajtani, hogy a célt teljesíteni tudja (buildelés elkészüljön). Ezeket pedig beépített feladatok (angolul: task) segítségével hajtja végre. Pl. a compile cél buildeléséhez először az Ant-nak készíteni kell egy classes nevű könyvtárat - ha még nem létezik - , majd meg kell hívnia a java fordítót. Ezt jelen esetben az mkdir és a javac feladatokat végrehajtásával érte el. Ez utóbbiak hasonlóan működnek, mint a hasonló nevű parancssori megfelelőik.

Egy másik jar nevű feladat használata ebben a példában:

<jar destfile="hello.jar">

Az ant feladatnak szintén ugyanaz a neve, mint a java parancssori eszközének: jar, de valójában az Ant program beépített jar/zip támogatás meghívását jelenti. A legtöbb felhasználónak, aki csak egy megfelelő jar fájlt akar, ez a kis részlet kérdés igazán nem lényeges. Sok Ant feladat delegálja munkáját külső programoknak, melyek lehetnek natív vagy java kódúak. Az Ant saját <exec> és <java> feladatait használják arra a célra, hogy a parancssori parancsot felépítsék a build fájl információiból és map-eljék az argumentumait a parancssori parancs argumentumaiként, végül interpretálják a visszatérési értéket. A felhasználó többféleképpen is megbizonyosodhat arról, melyik feladatok végzik a tényleges munkát (pl. <cvs>, <signjar>, <chmod>, <rpm>). Pl. megpróbálhatja végrehajtatni úgy a feladatot, hogy a kívánt program az elérési úton nem található (angolul: path), vagy esetleg úgy, hogy nem a teljes Java Development Kit van jelen futtatáskor.

WOProject-Ant^[5] csak egy példa a sok közül ant feladat kiterjesztésére. Ezeket a kiterjesztéseket úgy lehet működésre bírni, hogy a jar fájljaikat bemásoljuk az ant lib könyvtárába. Amint ezzel megvagyunk, ezek a kiterjesztett feladatok azonnal elérhetők a build.xml fájlból. A WOProject kiterjesztések megengedik WebObjects fejlesztőknek, hogy az antot használják a keretrendszerük és alkalmazásaik buildeléséhez Apple Xcode eszköze helyett.

Az Antcontrib^[6] olyan feladatok gyűjteményét adja, mint pl. a feltételes elágazó utasítások, műveletek properties fájlokon és még sok más feladat.^[7]

További feladat kiterjesztések léteznek pl. Perforce-hez, .Net-hez, EJB-hez, fájlrendszer manipulációkhoz csak néhányat megnevezzünk.^[8]

Az Ant létrejöttének egyik fő célja az volt, hogy megoldja a make hordozhatósági problémáit. Egy make fájlban a célokat leíró akciók shell parancsok formájában voltak megírva. Ezek pedig függtek az aktuális platformtól, amin futottak, legtöbbször valamiféle Unix-tól. Nagyszámú beépített funkcióval az Ant megoldotta ezeket a problémákat. Ezek garantálták a (közel) azonos lefutást minden platformon.

Például, a fenti példában a clean cél delegálja a classes könyvtár és alkönyvtárainak törlést a java osztálykönyvtárainak. Make fájlban ez tipikusan a következő paranccsal adható meg:

rm -rf classes/

rm egy Unix specifikus parancs, amely valószínűleg más nem Unix környezetben pl. Microsoft Windowsban nem elérhető. Itt mindez a következőképpen nézne ki:

rmdir /S /Q classes

Az Ant build fájlban mindez leírható a beépített feladatokkal:

<delete dir="classes"/>

A különböző platformok közti különbözőségre jó példa a könyvtár elérési útvonalainak megadása. A Unix /-t használ az útvonal elemek elválasztására, míg a Windows \-t használ ugyanerre. Az Ant build fájl a felhasználónak megengedi tetszőleges konvenció használatát. Azaz a könyvtárak szeparálására az \-t v. /-t, és az elérési útvonalak elválasztására ,-t v. ;-t. Végül futási időben mindezt konvertálja az adott platform megfelelő formátumára.

• Ant build fájlokat XML-ben írják. Sok hétköznapi felhasználónak akadályt jelenthet a tanulásban, mind maga XML, mind az Ant xml fájl komplex struktúrája (hierarchikus, részlegesen rendezett, kereszt hivatkozásokkal teli). Egy időben létezett egy Antidote nevű GUI felület, de egy idő után nem folytatták és végül visszavonták az Apache projektből. Továbbá a nyelv maga meglehetősen szószátyár, így a nagy komplexitású projektek build fájljai kezelhetetlenné válhatnak. A modularizáció és a gondos tervezés elősegítheti az olvashatóságot, de a méretet nem szükségszerűen csökkenti. Más build eszközök mint pl. az Maven sokkal tömörebb szkripteket használnak az általánosság és rugalmasság nevében.
• A régebbi taszkok — az ant magvát alkotó taszkok, amelyeket mindennap használunk pl. <javac>, <exec> és <java>— alapértelmezett értékeket használnak olyan opciókra, amelyek nem konzisztensek a taszk legújabb verziójával. Az alapértelmezett értékek megváltoztatása elrontaná a már létező ant szkripteket.
• Amikor kiterjesztünk egy properties értéket egy sztring v. szöveges elemben, a nem definiált properties érték nem dob hibát, de nem kiterjesztett referencia marad (pl. ${unassigned.property}).
• Antnak limitált hibakezelő képességei vannak. Nincs perzisztens állapot kezelés, ezért nem használható folyamat vezérlő eszközként(workflow), csakis a klasszikus build és teszt folyamatokhoz.
• Ha egyszer egy globális property érték definiálva lett, értéke nem változtatható meg egyik beépített (core) task-kal sem. Az Antcontrib változó task kal megoldható ez a probléma. Az AntXtras szintén nyújt változó property típust is, ami kiegészíti a csak olvasható properity-ket.
• Nem támogatja a lusta property kiértékelést. Pl. az antcontrib <for> cikluson belül, egy property nem értékelhető ki újra egy olyan új értékkel, amely része lehet az iterációnak is. (Persze ez megint megoldható egyéb kiterjesztések felhasználásával. AntXtras flow-contol takskset a ciklusok számára kurzor nyújt kurzor újradefiniálási lehetőséget).
• A build fájl részletek újrafelhasználása nehézkes. Ant 1.6 már megkönnyíti az újrafelhasználást, olyan lehetőségekkel mint az <import>, <presetdef>, és <macrodef>. Bár ezen új lehetőségek használhatósága abból a szempontból vitatható, hogy az új Ant felhasználótól még nagyobb odafigyelés kíván elsajátításuk.

Az angol Wikikönyvekben
további információk találhatók

Apache Ant témában.

• Maven

• Official website of Apache Ant
• Apache Ant wiki
• WinAnt - Windows installer for Apache Ant
• Introduction to Ant (slide show)
• Linguine Maps visualization library will automatically produce easy to read diagrams from Ant build files.
• antro - a profiler for Ant scripts
• Wiki Book on learning Apache Ant
• Ant tutorial
• Ant Automation, a good handy example of automation with Ant.
• A simple Windows GUI for running Ant.