ANT vs Maven vs Gradle

Mielőtt belemennénk az ANT, a Maven vagy a Gradle alkalmazásba, először meg kell értenünk néhány dolgot, ami velük kapcsolatos.

Függőség: A függőség általában arra utal, amikor valaminek szüksége van egy másik dologra ahhoz, hogy maga is végrehajtódjon. Egyszerűen fogalmazva, “A” függőséggel rendelkezik “B”-től, ha “A”-nak szüksége van “B”-re a sikeres végrehajtásához. A szoftverek világában a függőség minden olyan dolog, amelyre az alkalmazásnak szüksége van a sikeres végrehajtáshoz. Ez alapvetően bármilyen külső támogató könyvtár, amelyre az alkalmazásnak szüksége van. pl. zuul, hystrix, lombok, jdbc, stb.

Eredetileg úgy kezeltük a függőségeket, hogy:

• kézzel letöltöttük a szükséges könyvtár jar fájlját az internetről, és hozzáadtuk a projektünkhöz.
• írtunk egy szkriptet, amely automatikusan letölti a könyvtárat egy külső forrásból a hálózaton keresztül.

Az ezen eszközök előtt felmerülő problémák:

• A függőségek hozzáadása az internetről való kézi letöltéssel nagyon fárasztó feladat.
• A szkriptjeink meghibásodhatnak, ha a külső forrás URL címe megváltozik az interneten keresztül.
• Nagyon nehéz azonosítani és kezelni a tranzitív függőségeket az alkalmazásunkban.

A függőségkezelő eszköz: Feloldja és kezeli az alkalmazáshoz szükséges függőségeket.

Elkészítő eszköz: Automatizálja a futtatható alkalmazások létrehozását a forráskódból. Az építés magában foglalja a kód fordítását, összekapcsolását és csomagolását használható vagy futtatható formába. A build automatizálás magában foglalja:

1. A függőségek letöltése
2. A forráskód bináris kóddá fordítása
3. A bináris kód csomagolása
4. Tesztek futtatása
5. Telepítés a termelési rendszerekbe

A függőségkezelés és build eszközök java-ban:

• ANT + Ivy (2000/2004)
• Maven (2004)
• Gradle (2012)

Apache ANT (Another Neat Tool) az Apache nyílt forráskódú projektje, amelyet 2000-ben adtak ki. Ez egy java könyvtár, amelyet a java alkalmazások építési folyamatainak automatizálására használnak. Emellett nem java alkalmazások építéséhez is használható. A “Configuration over convention” elvét követi. Az Antban az építési folyamat különböző fázisait “célpontoknak” nevezik. Az ANT build fájlokat XML-ben írják, és a konvenció szerint “build.xml”-nek hívják őket. Három elemet tartalmaz: projekt, cél és feladat. Minden build fájl egy projektet tartalmaz. A build.xml-ben minden egyes dolog a project elem alatt található. A projekt legalább egy targetet tartalmaz (alapértelmezett). A target tartalmazza a benne lévő feladatok egy csoportját, és meghatározza a build folyamat egy adott állapotát. A task egy kódrészlet, amely végrehajtható. Minden csomóponthoz attribútumok tartozhatnak:

A Project attribútumai:

• Name: A projekt neve.
• Basedir: A projekt gyökérmappája, és nem kötelező.
• Alapértelmezett: Az építés alapértelmezett célpontja. A projektnek egy vagy több célpontja is lehet. A projekt alapértelmezett célpontjának megadására szolgál.

A Target attribútumai:

• Name: A célpont neve.
• Leírás: A célpont leírása.
• Depends: Az összes olyan célpont vesszővel elválasztott listája, amelytől ez a célpont függ.
• If: A célpont akkor kerül végrehajtásra, ha az attribútum igaz.
• Unless: A célpont akkor kerül végrehajtásra, ha az attribútum nincs beállítva.

Build.xml példa:

<?xml version="1.0"?>
<project>
<target name="hello">
<echo>Hello, World</echo> 
</target>
</project>

Függőség hozzáadása Ant + Ivy-ban:

<dependency org="org.projectlombok" name="lombok" rev="1.18.10"/>

Az Ant legfőbb előnye a rugalmassága. Az Ant nem kényszerít semmilyen kódolási konvenciót vagy projektstruktúrát a fejlesztőre. Következésképpen ez azt jelenti, hogy az Ant megköveteli a fejlesztőktől, hogy minden parancsot maguk írjanak meg, ami néha nagy build fájlokat eredményez, és nehezen karbantartható. Kezdetben az Ant nem rendelkezett beépített függőségkezelési támogatással. Később az Apache Ant projekt alprojektjeként fejlesztett Apache Ivy-t vette át függőségkezelés céljából.

Apache Maven

A 2004-ben megjelent függőségkezelő és build automatizáló eszköz. Továbbra is az XML-t használja, de a “Convention over configuration” elvét követve leküzdi a hátrányait. Konvenciókra támaszkodik, és előre definiált parancsokat (célokat) biztosít. Az építési és függőségkezelési utasításokat tartalmazó konfigurációs fájlját konvenció szerint “pom.xml”-nek hívják, és a projekt gyökérmappájában található.

A Maven motor a pom.xml-t és a projektet veszi be. Beolvassa a pom.xml fájlt, és az abban említett függőségeket jar fájlként letölti a helyi tárolóba. Ezután végrehajtja az életciklusokat, a build fázisokat és a bővítményeket. Végül egy csomagolt és tesztelt artefaktot generál.

pom.xml példa:

Egy pár fontos tag a pom.xml fájlban:

• groupId: Azt a szervezetet jelöli, amelyhez a projekt tartozik.
• artifactId: Ez a projekt neve.
• version: A projekt verzióját jelöli.
• packaging: A projekt építésének végső formáját jelenti. pl. jar, war.

Add dependency in maven:

<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.10</version>
</dependency>

Maven repository:

A repository egy olyan könyvtár, ahol az összes csomagolt jar fájl létezik a saját pom fájljaival együtt. Ezek a pom fájlok tartalmazzák az adott projekt külső függőségeit. Ily módon a maven rekurzív módon tölti le a projekt függőségi függőségeit, amíg az összes szükséges függőség meg nem jelenik a helyi tárolóban. A maven háromféle tároló létezik:

1. Helyi tároló:
2. Szervezeti szintű/távoli tároló:
3. Központi tároló: Ez egy internetes tároló, amelyet a maven közösség hozott létre és tart fenn.

Amikor egy projekt pom.xml fájljában egy függőség van megadva, a maven megkeresi azt a helyi tárolóban. Ha ott nem található meg, akkor a távoli/org wide repositoryban keresi meg. Ha ott sincs meg, akkor a központi repositoryban keresi.

A maven szigorú projektstruktúrát ír elő, míg az Ant ott is rugalmasságot biztosít. A szigorú konvencióknak az az ára, hogy sokkal kevésbé rugalmas, mint az Ant – a cél testreszabása nagyon nehéz.

A maven hátrányai:

1. A függőségkezelés nem kezeli jól a konfliktusokat ugyanazon könyvtár különböző verziói között.
2. A célok testreszabása nehéz.

Gradle

Ez egy 2012-ben megjelent nyílt forráskódú függőségkezelő és build automatizáló eszköz. Egyesíti az Apache Ant és az Apache Maven jó részeit, és ezekre építkezik, XML helyett pedig egy (Groovy alapú) domain-specifikus nyelvet használ. Rugalmasságát az Ant-tól, életciklusát pedig a Maven-től vette át. Emellett a “Convention over configuration” elvét követi. Támogatja a Maven és az Ivy tárolókat a függőségek lekérdezéséhez. Konfigurációs fájlja a konvenció szerint “build.gradle” néven ismert, és a projekt gyökérmappájában található. A Gradle az építési lépéseinek a “tasks” nevet adta, szemben az Ant “targets” vagy a Maven “phases” nevével. A Google elfogadta a Gradle-t az Android OS alapértelmezett build eszközeként.

A Gradle nem használ XML-t. Ehelyett saját Domain Specific Language-je volt, amely a Groovy-n (a JVM nyelvek egyikén) alapul. Ennek eredményeképpen a Gradle build szkriptek általában sokkal rövidebbek és egyértelműbbek, mint az Ant vagy a Maven számára írtak. A Boilerplate kód mennyisége sokkal kisebb a Gradle segítségével.

Gradle konfigurációk

• megvalósítás: Olyan függőségek deklarálására szolgál, amelyeket nem akarunk kitenni a fogyasztóinknak fordítási időben.
• api: Olyan függőségek deklarálására szolgál, amelyek az API-nk részét képezik, azaz olyan függőségekre, amelyeket kifejezetten ki akarunk tenni a fogyasztóinknak.
• compileOnly: Olyan függőségek deklarálását teszi lehetővé, amelyeknek csak fordítási időben kell rendelkezésre állniuk, de futási időben nincs rájuk szükség. Ennek a konfigurációnak a példája egy olyan annotációs processzor, mint a Lombok, amely fordítási időben módosítja a bytecode-ot. A fordítás után már nincs rá szükség, így a függőség futásidőben nem elérhető.
• runtimeOnly: Lehetővé teszi, hogy olyan függőségeket deklaráljunk, amelyekre fordítási időben nincs szükség, de futási időben elérhetőek lesznek. Egy példa erre az SLF4J, ahol a slf4j-api-t a implementation konfigurációhoz, az adott API implementációját (mint a slf4j-log4j12 vagy a logback-classic) pedig a runtimeOnly konfigurációhoz csatoljuk.
• testImplementation: Hasonló a implementation-hez, de a testImplementation-vel deklarált függőségek csak a tesztek fordítása és futtatása során állnak rendelkezésre. Használhatjuk olyan függőségek deklarálására olyan tesztelési keretrendszerekhez, mint a JUnit vagy a Mockito, amelyekre csak a tesztekben van szükségünk, és amelyek nem lehetnek elérhetőek a produktív kódban.
• testCompileOnly:
• testRuntimeOnly: Hasonlóan a compileOnly-hez, de a testCompileOnly-vel bejelentett függőségek csak a tesztek fordítása során állnak rendelkezésre, futásidőben nem.
• testRuntimeOnly: Hasonlóan a runtimeOnly-hez, de a testRuntimeOnly-vel deklarált függőségek csak a tesztek futási ideje alatt állnak rendelkezésre, fordítási időben nem.

Projektek és feladatok a Gradle-ben

Minden Gradle build egy vagy több projektből áll. Minden projekt feladatok egy halmazából áll. Minden feladat egy-egy munkát képvisel, amelyet a build végez, pl. JavaDoc generálása, néhány archívum közzététele egy repositoryban, stb.

build.gradle példa

Gradle repository:

A Gradle-ben az “aliasokat” abban az esetben használjuk, ha Maven repositoryt adunk hozzá a projektünk buildjéhez. Ezek az aliasok a következők:

• mavenCentral():
• jcenter(): Ez az alias a központi Maven 2 repositoryból lehívott függőségeket jelöli.
• jcenter(): Ez az alias a Bintray’s JCenter Maven repositoryból lehívott függőségeket jelöli.
• mavenLocal(): Ez az alias a helyi Maven-tárból lehívott függőségeket jelöli.

Példa: Adjuk hozzá a központi Maven-tárat a projektünkhöz, adjuk hozzá a következő kódrészletet a ‘build.gradle’ fájlunkhoz:

repositories {
mavenCentral()
}

Add dependency in Gradle:

compile group: 'org.hibernate', name: 'hibernate-core', version: '3.6.7.Final'

Előnyei:

1. A tranzitív függőségeket elég jól kezeli. Ha létezik konfliktusos tranzitív függőség a projektben, akkor annak feloldásához a függőség legújabb verzióját választja ki. Például az “A” függőség belsőleg megköveteli a “C” függőséget 2.0 verzióval, és a “B” függőség belsőleg megköveteli a “C” függőséget 3.0 verzióval. Ekkor a Gradle a ‘C’ függőség legújabb verzióját fogja használni.
2. A Gradle konfigurációs fájljai kisebb méretűek és tisztábbak, mivel XML helyett Groovy alapú, domain-specifikus nyelvet használ.
3. A Gradle inkrementális build koncepciót használ, és elkerüli a munkát azáltal, hogy követi a feladatok bemenetét és kimenetét, és csak azt futtatja, ami szükséges, és csak a megváltozott fájlokat dolgozza fel, ha lehetséges, és ezért gyorsabban teljesít, mint a maven.