TheNEXUS

A könyv szerzőinek nem áll szándékukban viszályt szítani azApache Ant és az Apache Maven között, de tisztában vagyunk azzal is, hogy a legtöbb szervezetnek döntenie kell a két szabványos megoldás között: Apache Ant és Apache Maven között. Ebben a fejezetben összehasonlítjuk és szembeállítjuk az eszközöket.

Az Ant a build-folyamatban jeleskedik, ez egy a mak után modellezett build-rendszer célokkal és függőségekkel. Minden target egy sor utasításból áll, amelyek XML-ben vannak kódolva. Van egy copy feladat és egyjavac feladat, valamint egy jar feladat. Az Ant használatakor az Antot konkrét utasításokkal látja el az output fordítására és csomagolására vonatkozóan. Nézze meg a következő példát egy egyszerű build.xml fájlra:

Egy egyszerű Ant build.xml fájl.

<project name="my-project" default="dist" basedir="."> <description> simple example build file </description> <!-- set global properties for this build --> <property name="src" location="src/main/java"/> <property name="build" location="target/classes"/> <property name="dist" location="target"/> <target name="init"> <!-- Create the time stamp --> <tstamp/> <!-- Create the build directory structure used by compile --> <mkdir dir="${build}"/> </target> <target name="compile" depends="init" description="compile the source " > <!-- Compile the java code from ${src} into ${build} --> <javac srcdir="${src}" destdir="${build}"/> </target> <target name="dist" depends="compile" description="generate the distribution" > <!-- Create the distribution directory --> <mkdir dir="${dist}/lib"/> <!-- Put everything in ${build} into the MyProject-${DSTAMP}.jar file --> <jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/> </target> <target name="clean" description="clean up" > <!-- Delete the ${build} and ${dist} directory trees --> <delete dir="${build}"/> <delete dir="${dist}"/> </target></project>

Ebben az egyszerű Ant-példában láthatja, hogy pontosan meg kell mondania az Antnak, hogy mit csináljon. Van egy fordítási cél, amely tartalmazza a javacfeladatot, amely lefordítja a src/main/java könyvtárban lévő forrást acél/classes könyvtárba. Meg kell mondania az Antnak, hogy pontosan hol van a forrása, hol akarja tárolni az eredményül kapott bytecode-ot, és hogyan csomagolja mindezt egy JAR fájlba. Bár vannak olyan legújabb fejlesztések, amelyek segítenek abban, hogy az Ant kevésbé procedurális legyen, a fejlesztőnek az Ant-tal kapcsolatos tapasztalata egy XML-ben írt procedurális nyelv kódolásában van.

Hasonlítsa össze az előző Ant példát egy Maven példával. A Mavenben egy JAR fájl létrehozásához valamilyen Java forrásból, csak annyit kell tennie, hogy létrehoz egy egyszerű pom.xml-t, elhelyezi a forráskódját a${basedir}/src/main/java könyvtárban, majd futtatja a mvn install parancssorból. Az A Simple Ant build.xml fájlban felsorolt egyszerű Ant-fájlhoz hasonló eredményeket elérő Maven pom.xml példa láthatóA Sample Maven pom.xml.

A Sample Maven pom.xml.

<project> <modelVersion>4.0.0</modelVersion> <groupId>org.sonatype.mavenbook</groupId> <artifactId>my-project</artifactId> <version>1.0</version></project>

Ez minden, amire szüksége van a pom.xml-ben. A mvn install parancssorból történő futtatása feldolgozza az erőforrásokat, lefordítja a forrást, végrehajtja az unittesteket, létrehoz egy JAR-t, és telepíti a JAR-t egy helyi tárolóba más projektekben való újrafelhasználás céljából. Módosítás nélkül futtathatja a mvn sitefuttatást, majd a target/site-ban talál egy index.html fájlt, amely tartalmazza a JavaDoc-ra mutató linkeket és néhány jelentést a forráskódjáról.

Kétségtelen, hogy ez a lehető legegyszerűbb példaprojekt, amely nem tartalmaz mást, mint némi forráskódot és egy egyszerű JAR-t állít elő. Ez egy olyan projekt, amely szorosan követi a Maven konvenciókat, és nem igényel semmilyen függőséget vagy testreszabást. Ha el akarnánk kezdeni a viselkedés testreszabását, a pom.xml-ünk mérete növekedni fog, és a legnagyobb projektekben nagyon összetett Maven POM-ok gyűjteményeit láthatjuk, amelyek rengeteg plugin testreszabást és függőségi nyilatkozatot tartalmaznak. De még akkor is, ha a projektünk POM fájljai jelentősebbé válnak, teljesen másfajta információt tartalmaznak, mint egy hasonló méretű, Antot használó projekt build fájlja. A Maven POM-ok deklarációkat tartalmaznak: “Ez egy JAR projekt”, és “A forráskód az src/main/java-ban található”. Az Ant build fájlok explicit utasításokat tartalmaznak: “This is project”, “The source is in src/main/java”, “Run javacagainst this directory”, “Put the results in target/classes”, “Create a JAR from the ….”, stb. Míg az Antnak explicitnek kellett lennie a folyamatot illetően, a Mavenben volt valami “beépített”, ami egyszerűen tudta, hogy hol van a forráskód és hogyan kell feldolgozni.

Az Ant és a Maven közötti különbségek ebben a példában a következők:

A Maven beépített intelligenciával rendelkezik a közös projektfeladatokról a Maven pluginek formájában. Ha egységteszteket szeretne írni és végrehajtani, csak annyit kell tennie, hogy megírja a teszteket, elhelyezi őket a${basedir}/src/test/java könyvtárban, hozzáad egy teszt-hatályos függőséget akár a TestNG-től, akár a JUnit-től, és futtatja a mvn test. Ha aweb alkalmazást szeretne telepíteni és nem JAR-t, akkor csak annyit kell tennie, hogy a projekt típusát war-re változtatja, és a docroot-ot a${basedir}/src/main/webapp helyre teszi. Persze, mindezt megteheti azAnt programmal is, de akkor a semmiből kell megírnia az utasításokat. Antban először ki kell találnia, hogy hol legyen a JUnit JAR fájl. Ezután létre kell hoznia egy olyan classpath-ot, amely tartalmazza a JUnitJAR fájlt. Ezután meg kell mondania az Antnak, hogy hol keressen teszt forráskódot, írnia kell egy célt, amely a teszt forrást bytecode-ba fordítja, és a JUnit segítségével végrehajtja az egységteszteket.

Az Ant olyan támogató technológiák nélkül, mint az antlibs és az Ivy (még ezekkel a támogató technológiákkal együtt is), az Ant olyan érzést kelt, mint egy c`szokásos proceduralbuild. Egy hatékony Maven POM-készlet egy olyan projektben, amely betartja aMaven feltételezett konvencióit, meglepően kevés XML-t tartalmaz az Ant alternatívájához képest. A Maven másik előnye a széles körben megosztott Maven bővítményekre való támaszkodás. Mindenki a Maven Surefire plugint használja az egységteszteléshez, és ha valaki egy új egységtesztelési keretrendszer támogatását adja hozzá, akkor új képességeket nyerhet a saját építésében azáltal, hogy egyszerűen növeli egy adott Maven plugin verzióját a projekt POM-jában.

A Maven vagy Ant használata nem bináris döntés, és az Antnak még mindig van helye egy komplex építésben. Ha a jelenlegi buildje tartalmaz valamilyen erősen testreszabott folyamatot, vagy ha írt néhány Ant szkriptet egy adott folyamat speciális módon történő befejezésére, amely nem igazítható a Maven szabványokhoz, akkor ezeket a szkripteket továbbra is használhatja a Maven segítségével. Az Ant egy alapvető Maven bővítményként válik elérhetővé. Egyedi Maven bővítményeket lehet megvalósítani az Antben, és a Maven projektek konfigurálhatók úgy, hogy a Maven projekt életciklusán belül az Ant szkripteket futtassák.