streamalism.org

Ez a cikk egy sorozat része: • Bevezetés a Gradle-be

• Ant vs Maven vs Gradle (aktuális cikk) • Egyéni Gradle beépülő modulok írása

• Zsíros edény létrehozása Gradle-ben

1. Bemutatkozás

Ebben a cikkben feltárjuk három Java építési automatizálási eszköz, amely uralta a JVM ökoszisztémát - Ant, Maven és Gradle.

Bemutatjuk mindegyiket, és feltárjuk, hogyan fejlődtek a Java build automatizálási eszközök.

2. Apache Ant

Kezdetben a Make volt az egyetlen build automatizálási eszköz a saját megoldásokon túl elérhető. A Make 1976 óta létezik, és mint ilyen, a Java korai éveiben Java alkalmazások építésére használták.

A C programok sok konvenciója azonban nem illett be a Java ökoszisztémába, így idővel az Ant vette át a jobb alternatívát.

Az Apache Ant („Another Neat Tool”) egy Java könyvtár, amelyet a Java alkalmazások összeállítási folyamatainak automatizálására használnak. Ezenkívül az Ant felhasználható nem Java alkalmazások készítésére. Eleinte az Apache Tomcat kódbázis része volt, és 2000-ben önálló projektként jelent meg.

Az Ant sok szempontból nagyon hasonlít a Make-hez, és elég egyszerű, így bárki különösebb előfeltételek nélkül elkezdheti használni. Az Ant build fájlokat XML-ben írják, és megegyezés szerint hívják őket build.xml.

A gyártási folyamat különböző szakaszait „céloknak” nevezzük.

Itt van egy példa a build.xml fájl egy egyszerű Java projekthez a Helló Világ főosztály:

Ez a build fájl négy célt határoz meg: tiszta, összeállítani, befőttes üveg és fuss. Például a kód futtatásával állíthatjuk össze:

hangya össze

Ez kiváltja a célt tiszta először törölni fogja az „osztályok” könyvtárat. Ezt követően a cél összeállítani újra létrehozza a könyvtárat és lefordítja az src mappát.

A Hangya legfőbb előnye a rugalmassága. A Hangya nem ír elő kódolási konvenciókat vagy projektszerkezeteket. Következésképpen ez azt jelenti, hogy az Ant megköveteli a fejlesztőktől, hogy az összes parancsot saját maguk írják meg, ami néha hatalmas XML build fájlokhoz vezet, amelyeket nehéz fenntartani.

Mivel nincsenek konvenciók, a Hangya ismerete nem jelenti azt, hogy gyorsan megértenénk bármely Ant szerkesztő fájlt. Valószínűleg eltart egy ideig, amíg megszokja az ismeretlen Ant fájlt, ami hátrányt jelent a többi, újabb eszközhöz képest.

Eleinte Antnak nem volt beépített támogatása a függőségkezeléshez. Mivel azonban a későbbiekben elengedhetetlenné vált a függőségkezelés, az Apache Ivy-t az Apache Ant projekt részprojektjeként fejlesztették ki. Integrálva van az Apache Ant-ba, és ugyanazokat a tervezési elveket követi.

Azonban a kezdeti Ant korlátozások, amelyek a függőségkezelés beépített támogatásának és a csalódásoknak tudhatók be, amikor kezelhetetlen XML build fájlokkal dolgoztak, Maven létrehozásához vezettek.

3. Apache Maven

Az Apache Maven egy függőségkezelő és egy build automatizáló eszköz, amelyet elsősorban Java alkalmazásokhoz használnak. Maven továbbra is használja az XML fájlokat, mint az Ant, de sokkal kezelhetőbb módon. A játék neve itt egyezmény a konfiguráció felett.

Míg a Hangya rugalmasságot biztosít és megköveteli, hogy mindent a semmiből írjon, Maven konvenciókra támaszkodik, és előre definiált parancsokat (célokat) ad.

Egyszerűen fogalmazva: Maven lehetővé teszi számunkra, hogy arra összpontosítsunk, mit kell csinálnunk az építésünknek, és megadja a keretet ahhoz, hogy ezt elvégezzük. A Maven másik pozitív szempontja, hogy beépített támogatást nyújtott a függőségkezeléshez.

A Maven konfigurációs fájlját, amely a build és a függőségkezelés utasításait tartalmazza, konvenció szerint hívják pom.xml. Ezenkívül Maven szigorú projektstruktúrát is előír, míg a Hangya ott is rugalmasságot biztosít.

Itt van egy példa a pom.xml fájl ugyanazon egyszerű Java projekthez a Helló Világ főosztály korábban:

 Példa 0.0.1-SNAPSHOT Maven példa junit junit 4.12 teszt 

Most azonban a projekt felépítését is egységesítették, és megfelel a Maven-konvencióknak:

+ --- src | + --- fő | | + --- java | | | \ --- com | | | \ --- baeldung | | | \ --- maven | | | HelloWorld.java | | | | | \ --- források | \ --- teszt | + --- java | \---erőforrások

Az Antival ellentétben nincs szükség a készítési folyamat egyes fázisainak manuális meghatározására. Ehelyett egyszerűen felhívhatjuk Maven beépített parancsait.

Például a kód futtatásával állíthatjuk össze:

mvn össze

Lényegében, amint azt a hivatalos oldalak megjegyzik, A Maven plugin végrehajtási keretrendszernek tekinthető, mivel minden munkát pluginok végeznek. A Maven a rendelkezésre álló bővítmények széles skáláját támogatja, és mindegyik további konfigurálható.

Az egyik elérhető plugin az Apache Maven Dependency Plugin, amelynek a másolás-függőségek cél, amely átmásolja a függőségeinket egy megadott könyvtárba.

Ha ezt a bővítményt működés közben szeretnénk megjeleníteni, vegyük fel ezt a bővítményt a mi oldalunkba pom.xml fájlt, és konfiguráljon egy kimeneti könyvtárat a függőségeinkhez:

   org.apache.maven.plugins maven-dependency-plugin copy-dependencies csomag copy-dependencies target / dependencies 

Ez a beépülő modul a csomag szakasz, tehát ha futunk:

mvn csomag

Végrehajtjuk ezt a bővítményt, és a függőségeket átmásoljuk a cél / függőségek mappába.

Van egy létező cikk arról is, hogy miként hozhatunk létre futtatható JAR-ot a különböző Maven beépülő modulok használatával. Ezenkívül a részletes Maven-áttekintés érdekében tekintse meg ezt a Maven fő útmutatóját, ahol Maven néhány főbb jellemzőjét feltárják.

A Maven nagyon népszerűvé vált, mivel a build fájlokat már szabványosították, és az Ant fájlhoz képest lényegesen kevesebb időbe került a build fájlok fenntartása. Bár a szabványosítottabbak, mint az Ant fájlok, a Maven konfigurációs fájlok még mindig nagyok és nehézkesek.

Maven szigorú konvenciói azzal járnak, hogy sokkal kevésbé rugalmasak, mint Ant. A célok testreszabása nagyon nehéz, ezért az egyedi összeállítású szkriptek írása sokkal nehezebb, mint az Ant.

Bár a Maven komoly fejlesztéseket hajtott végre az alkalmazás építési folyamatainak egyszerűbbé és szabványosabbá tételében, ennek ellenére ára van, mivel sokkal kevésbé rugalmas, mint az Ant. Ez a Gradle létrehozásához vezetett, amely egyesíti a két világ legjobbjait - Ant rugalmasságát és Maven tulajdonságait.

4. Gradle

A Gradle egy függőségkezelés és egy build automatizálási eszköz, amely Ant és Maven koncepcióira épült.

Az egyik első dolog, amit megjegyezhetünk a Gradle kapcsán, hogy nem használ XML fájlokat, ellentétben az Antival vagy a Maven-kel.

Az idő múlásával a fejlesztők egyre jobban érdeklődtek egy tartományspecifikus nyelv iránt és az iránt való együttműködés iránt - ami egyszerűen megfogalmazva lehetővé tenné számukra, hogy az adott tartományra szabott nyelv segítségével megoldják a problémákat egy adott tartományban.

Ezt Gradle fogadta el, amely vagy Groovy, vagy Kotlin alapú DSL-t használ. Ez kisebb konfigurációs fájlokhoz vezetett, kevesebb rendetlenséggel, mivel a nyelvet kifejezetten speciális tartományi problémák megoldására tervezték. Gradle konfigurációs fájlját egyezmény szerint hívják épít.gradle a Groovy-ban, vagy build.gradle.kts Kotlinban.

Figyelje meg, hogy Kotlin a Groovy-nál jobb IDE támogatást kínál az automatikus kiegészítéshez és a hibák felderítéséhez.

Itt van egy példa a épít.gradle fájl ugyanarra az egyszerű Java projektre a Helló Világ főosztály korábban:

plugin alkalmazása: 'java' adattárak {mavenCentral ()} jar {baseName = 'gradleExample' version = '0.0.1-SNAPSHOT'} függőségek {testImplementation 'junit: junit: 4.12'}

A kódot a következő futtatással állíthatjuk össze:

évfolyam osztályok

Lényegében a Gradle szándékosan nagyon kevés funkcionalitást nyújt. A beépülő modulok hozzáadnak minden hasznos funkciót. Példánkban azt használtuk Jáva plugin, amely lehetővé teszi számunkra a Java kód és más értékes szolgáltatások összeállítását.

Gradle építési lépéseinek „feladatok” nevet adott, szemben Ant „célpontjaival” vagy Maven „fázisaival”. A Mavennel az Apache Maven Dependency Plugint használtuk, és konkrét cél a függőségek átmásolása egy megadott könyvtárba. A Gradle segítségével ugyanezt megtehetjük a feladatok használatával is:

feladat copyDependencies (típus: Másolás) {from configigurations.compile into 'dependencies'}

Ezt a feladatot az alábbiak végrehajtásával futtathatjuk:

gradle copyDependences

5. Következtetés

Ebben a cikkben bemutattuk az Ant, Maven és Gradle - három Java build automatizálási eszközt.

Nem meglepő, hogy ma Maven birtokolja az építőeszközök piacának többségét.

Gradle azonban a következő okok miatt jól alkalmazkodott a bonyolultabb kódbázisokhoz:

• Sok nyílt forráskódú projekt, például a Spring használja most
• Inkrementális felépítésének köszönhetően a legtöbb esetben gyorsabb, mint a Maven
• Fejlett elemzési és hibakeresési szolgáltatásokat kínál

Úgy tűnik azonban, hogy Gradle-nek meredekebb a tanulási görbéje, különösen, ha nem ismeri Groovyt vagy Kotlint.

Következő » Egyéni Gradle bővítmények írása « A Gradle előző bemutatása