TheNEXUS

1.7. Srovnání Mavenu s Ant

Autoři této knihy nemají zájem vytvářet spor meziApache Ant a Apache Maven, ale jsme si vědomi i toho, že většina organizací se musí rozhodovat mezi těmito dvěmastandardními řešeními: Apache Ant a Apache Maven. V této části nástroje srovnáme a porovnáme.

Ant vyniká v procesu sestavování, je to systém sestavování po vzoru makes cíli a závislostmi. Každý cíl se skládá ze sadyinstrukcí, které jsou zakódovány v XML. K dispozici je úloha copy a úlohajavac a také úloha jar. Když používáte Ant, poskytujete mu specifické instrukce pro kompilaci a zabalení výstupu. Podívejte se na následující příklad jednoduchého souboru build.xml:

Jednoduchý soubor build.xml aplikace Ant.

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

V tomto jednoduchém příkladu Ant vidíte, jak musíte Antu přesně říct, co má dělat. Je zde cíl kompilace, který obsahuje javacúkol, který zkompiluje zdrojový kód v adresáři src/main/java do adresářetarget/classes. Musíte Antu přesně říct, kde je vášzdroj, kde má být uložen výsledný bajtový kód a jakto vše zabalit do souboru JAR. Přestože existují některé nedávnévývoje, které pomáhají udělat Ant méně procedurálním, vývojářova zkušenost s Ant je v kódování procedurálního jazyka zapsaného v XML.

Srovnejte předchozí příklad Ant s příkladem Maven. V Mavenu stačí pro vytvoření souboru JAR z nějakého zdrojového kódu v jazyce Java vytvořit jednoduchý soubor pom.xml, umístit zdrojový kód do adresáře${basedir}/src/main/java a pak spustit mvn install z příkazového řádku. Příklad souboru Maven pom.xml, který dosahuje stejnýchvýsledků jako jednoduchý soubor Ant uvedený v části Jednoduchý soubor Ant build.xml, je uveden v částiUkázka souboru Maven pom.xml.

Ukázka souboru Maven pom.xml.

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

To je vše, co potřebujete ve svém souboru pom.xml. Spuštění příkazu mvn install z příkazového řádku zpracuje zdroje, zkompiluje zdrojový kód, provede unittesty, vytvoří JAR a nainstaluje JAR do místního úložiště pro opakované použití v jiných projektech. Bez úprav můžete spustit mvn sitea pak najít soubor index.html v target/site, který obsahuje odkazy na JavaDoc a několik zpráv o vašem zdrojovém kódu.

Přiznejme, že toto je nejjednodušší možný příklad projektu, který neobsahuje nic víc než nějaký zdrojový kód a vytváří jednoduchý JAR. Je to projekt, který přesně dodržuje konvence Mavenu a nevyžaduje žádné závislosti ani přizpůsobení. Pokud bychom chtěli začít přizpůsobovat chování, náš pom.xml se zvětší a v největších projektech můžete vidět sbírky velmi složitých Maven POMů, které obsahují velké množství přizpůsobení zásuvných modulů a deklarací závislostí. Ale i když se soubory POM vašeho projektu stanou rozsáhlejšími, obsahují zcela jiný druh informací než soubor pro sestavení podobně velkého projektu používajícího Ant. POMy Mavenu obsahují deklarace: „Toto je projekt JAR“ a „Zdrojový kód je v src/main/java“. Sestavovací soubory Ant obsahují explicitní instrukce: „Toto je projekt“, „Zdrojový kód je v src/main/java“, „Spusť javacv tomto adresáři“, „Výsledky vlož do target/classes“, „Vytvoř JAR z ….“ atd. Tam, kde Ant musel být explicitní ohledně procesu, bylo v Mavenu něco „vestavěného“, co prostě vědělo, kde je zdrojový kód a jak má být zpracován.

Rozdíly mezi Ant a Maven v tomto příkladu jsou:

  • Apache Ant

    • Ant nemá formální konvence, jako je společná adresářová struktura projektu nebo výchozí chování. Musíte Antu přesně říct, kde má najít zdrojový kód a kam má umístit výstup. Neformální konvence vznikly v průběhu času, ale nebyly kodifikovány do produktu.
    • Ant je procedurální. Musíte Antu přesně říct, co má dělat a kdy to má dělat. Musíte mu říct, aby kompiloval, pak kopíroval a pak komprimoval.
    • Ant nemá životní cyklus. Musíte definovat cíle a závislosti cílů. Ke každému cíli musíte ručně připojit posloupnost úloh.
  • Apache Maven

    • Maven má konvence. Ví, kde se nachází váš zdrojový kód, protože jste se řídili konvencí. Zásuvný modul kompilátoru Maven umístí bajtový kód do target/classes a v targetu vytvoří soubor JAR.
    • Maven je deklarativní. Stačilo vytvořit soubor pom.xml a umístit zdrojový kód do výchozího adresáře. O zbytek se postaral Maven.
    • Maven má životní cyklus, který byl vyvolán při spuštění mvn install. Tento příkaz řekl Mavenu, aby provedl řadu postupných fází životního cyklu, dokud nedosáhne fáze životního cyklu instalace. Jako vedlejší efekt této cesty životním cyklem provedl Maven řadu výchozích cílů zásuvných modulů, které dělaly věci jako kompilace a vytvoření JAR.

Maven má zabudovanou inteligenci o běžných projektových úlohách v podobě zásuvných modulů Maven. Pokud byste chtěli psát a spouštět jednotkové testy, stačilo by napsat testy, umístit je do adresáře${basedir}/src/test/java, přidat závislost s testovací oblastí buď TestNG, nebo JUnit a spustit mvn test. Pokud byste chtěli nasadit webovou aplikaci, a ne JAR, stačilo by změnit typ projektu na war a umístit docroot do${basedir}/src/main/webapp. Jistě, tohle všechno můžete udělat pomocíAnt, ale budete psát návod od začátku. V nástroji Ant budete muset nejprve zjistit, kde má být soubor JUnit JAR. Pak byste museli vytvořit cestu tříd, která by obsahovala soubor JUnitJAR. Pak byste Antu řekli, kde má hledat zdrojový kód testů, napsali byste cíl, který zkompiluje zdrojový kód testů do bajtkódu, a provedli byste jednotkové testy pomocí JUnit.

Bez podpůrných technologií, jako jsou antlibs a Ivy (i s těmito podpůrnými technologiemi), má Ant pocit c`vlastního procedurálního sestavení. Efektivní sada Maven POM v projektu, který dodržujeMavenem předpokládané konvence, má překvapivě málo XML ve srovnání s alternativou Ant. Další výhodou Mavenu je závislost na široce sdílených pluginech Mavenu. Všichni používají zásuvný modul Maven Surefire pro testování jednotek, a pokud někdo přidá podporu nového frameworku pro testování jednotek, můžete získat nové možnosti ve svém vlastním sestavení pouhým zvýšením verze konkrétního zásuvného modulu Maven v POM vašeho projektu.

Rozhodnutí, zda použít Maven nebo Ant, není binární a Ant má stále své místo v komplexním sestavení. Pokud vaše současné sestavení obsahuje nějaký vysoce přizpůsobený proces nebo pokud jste napsali nějaké skripty Ant pro dokončení určitého procesu specifickým způsobem, který nelze přizpůsobit standardůmMaven, můžete tyto skripty stále používat s Mavenem. Ant je k dispozici jako základní zásuvný modul Mavenu. Vlastní zásuvné moduly Mavenu lze implementovat v Antu a projekty Maven lze nakonfigurovat tak, aby v rámci životního cyklu projektu Maven prováděly skriptyAnt.

Leave a Reply