TheNEXUS

Autorii acestei cărți nu au nici un interes în a crea o dușmănie întreApache Ant și Apache Maven, dar suntem, de asemenea, conștienți de faptul că majoritatea organizațiilor trebuie să ia o decizie între cele două soluții standard: Apache Ant și Apache Maven. În această secțiune, comparăm și contrastăm instrumentele.

Ant excelează la procesul de construire, este un sistem de construire modelat după makecu ținte și dependențe. Fiecare țintă constă într-un set deinstrucțiuni care sunt codificate în XML. Există o sarcină copy și o sarcinăjavac, precum și o sarcină jar. Atunci când utilizați Ant, îi furnizați lui Antinstrucțiuni specifice pentru compilarea și împachetarea rezultatului dumneavoastră. Priviți următorul exemplu de fișier build.xml simplu:

Un fișier Ant build.xml simplu.

<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>

În acest exemplu simplu de Ant, puteți vedea cum trebuie să-i spuneți lui Antexactly ce să facă. Există un obiectiv de compilare care include javactask-ul care compilează sursa din directorul src/main/java în directorultarget/classes. Trebuie să îi spuneți lui Ant exact unde se află sursa dumneavoastră, unde doriți ca bytecode-ul rezultat să fie stocat și cum să împachetați totul într-un fișier JAR. Deși există unele dezvoltări recente care ajută să îl facă pe Ant mai puțin procedural, experiența unui dezvoltator cu Ant constă în codificarea unui limbaj procedural scris în XML.

Contrastând exemplul Ant anterior cu un exemplu Maven. În Maven, pentru a crea un fișier JAR dintr-o sursă Java, tot ce trebuie să faceți este să creați un pom.xml simplu, să plasați codul sursă în ${basedir}/src/main/java și apoi să rulați mvn install din linia de comandă. Exemplul Maven pom.xml care obține aceleași rezultate ca și fișierul simplu Ant listat în A Simple Ant build.xml file este prezentat înA 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>

Acesta este tot ce aveți nevoie în pom.xml. Rularea mvn install din linia de comandă va procesa resursele, va compila sursa, va executa unittests, va crea un JAR și va instala JAR-ul într-un depozit local pentru a fi reutilizat în alte proiecte. Fără modificări, puteți rula mvn siteși apoi să găsiți un fișier index.html în target/site care conține linkuri către JavaDoc și câteva rapoarte despre codul dvs. sursă.

Admitem că acesta este cel mai simplu proiect de exemplu posibil care nu conține nimic mai mult decât niște cod sursă și produce un JAR simplu. Este un proiect care urmează îndeaproape convențiile Maven și nu necesită nici o dependență sau personalizare. Dacă am dori să începem să personalizăm comportamentul, pom.xml-ul nostru va crește în dimensiune, iar în cele mai mari proiecte se pot vedea colecții de POM-uri Maven foarte complexe care conțin o mare cantitate de personalizare a plugin-urilor și declarații de dependențe. Dar, chiar și atunci când fișierele POM ale proiectului dvs. devin mai substanțiale, ele conțin un tip de informații cu totul diferit de fișierul de construcție al unui proiect de dimensiuni similare care utilizează Ant. POM-urile Maven conțin declarații: „Acesta este un proiect JAR” și „Codul sursă se află în src/main/java”. Fișierele de construcție Ant conțin instrucțiuni explicite: „Acesta este un proiect”, „Sursa se află în src/main/java”, „Rulați javac în acest director”, „Puneți rezultatele în target/classes”, „Creați un JAR din ….” etc. În timp ce Ant trebuia să fie explicit cu privire la proces, exista ceva „încorporat” în Maven care știa pur și simpluunde se află codul sursă și cum trebuie procesat.

Diferențele dintre Ant și Maven în acest exemplu sunt:

Maven are inteligență încorporată cu privire la sarcinile comune ale proiectului sub formă de plugin-uri Maven. Dacă ați dori să scrieți și să executați teste unitare, tot ce ar trebui să faceți este să scrieți testele, să le plasați în ${basedir}/src/test/java, să adăugați o dependență de testare fie TestNG, fie JUnit și să rulați mvn test. Dacă ați dori să implementați o aplicație web și nu un JAR, tot ce ar trebui să faceți este să vă schimbați tipul de proiect în war și să plasați docrootul în ${basedir}/src/main/webapp. Desigur, puteți face toate acestea cuAnt, dar veți scrie instrucțiunile de la zero. În Ant, va trebui mai întâi să vă dați seama unde ar trebui să fie fișierul JAR JUnit. Apoi ar trebui să creați un classpath care să includă fișierul JUnitJAR. Apoi, ar trebui să-i spuneți lui Ant unde ar trebui să caute codul sursă de test, să scrieți un obiectiv care să compileze sursa de test în bytecode și să executați testele unitare cu JUnit.

Fără tehnologii de suport cum ar fi antlibs și Ivy (chiar și cu aceste tehnologii de suport), Ant are sentimentul unui c`ustom proceduralbuild. Un set eficient de POM-uri Maven într-un proiect care aderă la convențiile asumate deMaven are surprinzător de puțin XML în comparație cu alternativa Ant. Un alt beneficiu al Maven este dependența de plugin-urile Maven partajate la scară largă. Toată lumea folosește pluginul Maven Surefire pentru testarea unităților, iar dacă cineva adaugă suport pentru o nouă structură de testare a unităților, puteți obține noi capabilități în propria construcție prin simpla creștere a versiunii unui anumit plugin Maven în POM-ul proiectului dumneavoastră.

Decizia de a folosi Maven sau Ant nu este una binară, iar Ant are încă un loc într-o construcție complexă. Dacă construcția dvs. curentă conține un proces foarte personalizat sau dacă ați scris niște scripturi Ant pentru a finalizaun proces specific într-un mod specific care nu poate fi adaptat la standardeleMaven, puteți folosi în continuare aceste scripturi cu Maven. Ant este pus la dispoziție ca un plugin Maven de bază. Plugin-urile Maven personalizate pot fiimplementate în Ant, iar proiectele Maven pot fi configurate pentru a executa scripturi Ant în cadrul ciclului de viață al proiectului Maven.

.