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]
build.xml
fájlA 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.
<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.