Bevezetés a Gradle-be
• Egyéni fokozatok beépítése
• Zsíros edény létrehozása Gradle-ben
1. Áttekintés
A Gradle egy Groovy-alapú build-kezelő rendszer, amelyet kifejezetten Java-alapú projektek építésére terveztek.
A telepítési útmutató itt található.
2. Építőelemek - Projektek és feladatok
A Gradle-ben a Builds egy vagy több projektből áll, és minden projekt egy vagy több feladatból áll.
Gradle-ben egy projekt összeállítható a befőttes üveg, háború vagy akár a postai irányítószám fájl.
A feladat egyetlen munka. Ez magában foglalhatja osztályok összeállítását, vagy Java / web archívumok létrehozását és közzétételét.
Egy egyszerű feladat a következőképpen határozható meg:
helló {doLast {println 'Baeldung'}}Ha a fenti feladatot a gradle -q szia parancs ugyanarról a helyről, ahol épít.gradle tartózkodik, látnunk kell a kimenetet a konzolon.
2.1. Feladatok
Gradle építési szkriptjei nem mások, mint Groovy:
task toLower {doLast {String someString = 'HELLO FROM BAELDUNG' println "Eredeti:" + someString println "Kisbetű:" + someString.toLowerCase ()}}Meghatározhatunk olyan feladatokat, amelyek más feladatoktól függenek. A feladatfüggőség meghatározható a dependOn: taskName argumentum a feladat definíciójában:
feladat helloGradle {doLast {println 'Hello Gradle!' }} feladat a Baeldung-tól (attól függOn: helloGradle) {doLast {println "Baeldungból származom"}}2.2. Viselkedés hozzáadása egy feladathoz
Meghatározhatunk egy feladatot, és további viselkedéssel javíthatjuk:
feladat helloBaeldung {doLast {println 'Majd másodszor hajtanak végre'}} helloBaeldung.doFirst {println 'engem hajtanak végre először'} helloBaeldung.doLast {println 'engem harmadszor hajtanak végre'} helloBaeldung {doLast {println 'én leszek végrehajtva negyedik '}}doFirst és doLast adjon hozzá műveleteket a cselekvési lista tetejére, illetve aljára, és egyetlen feladatban többször is meghatározható.
2.3. Feladat tulajdonságainak hozzáadása
Meghatározhatjuk a tulajdonságokat is:
feladat ourTask {ext.theProperty = "theValue"} Itt állunk "az érték" mint a tulajdon a mi Feladat feladat.
3. A beépülő modulok kezelése
Kétféle plugin van a Gradle-ben - forgatókönyv, és bináris.
A kiegészítő funkciók kihasználásához minden bővítménynek két szakaszon kell keresztülmennie: megoldása és alkalmazva.
Megoldás azt jelenti, hogy megtalálja a plugin jar helyes verzióját, és hozzáadja azt a osztályút a projektről.
Jelentkezés a plugins végrehajtja Plugin.apply (T)a projekten.
3.1. Script beépülő modulok alkalmazása
Ban,-ben aplugin.gradle, meghatározhatunk egy feladatot:
task fromPlugin {doLast {println "A pluginból származom"}}Ha ezt a bővítményt alkalmazni akarjuk a projektünkben épít.gradle fájlt, csak annyit kell tennünk, hogy hozzáadjuk ezt a sort a épít.gradle:
alkalmazza: 'aplugin.gradle' Most kivégez fokozatos feladatok parancsnak meg kell jelenítenie a fromPlugin feladat a feladatlistán.
3.2. Bináris bővítmények alkalmazása Plugins DSL használatával
Mag bináris plugin hozzáadása esetén rövid neveket vagy plugin azonosítót adhatunk hozzá:
bővítmények {id 'application'}Most a fuss feladatot Alkalmazás plugineknek elérhetőnek kell lenniük egy projektben bármelyik végrehajtásához futható befőttes üveg. A közösségi plugin alkalmazásához meg kell említenünk egy teljesen minősített plugin azonosítót:
bővítmények {id "org.shipkit.bintray" verzió "0.9.116"}Most, Hajókészlet a feladatoknak elérhetőnek kell lenniük a fokozatos feladatok lista.
A DSL beépülő modulok korlátai a következők:
- Nem támogatja a Groovy kódot a bővítmények Blokk
- bővítmények blokknak a legfejlettebb utasításnak kell lennie a projekt build szkriptjeiben (csak buildscripts {} blokk engedélyezett előtte)
- A DSL bővítmények nem írhatók szkriptek beépülő modulba, beállítások.gradle fájlban vagy init szkriptekben
A DSL beépülő modulok még inkubálódnak. A DSL és más konfiguráció megváltozhat a későbbi Gradle verziókban.
3.3. A beépülő modulok alkalmazásának régi eljárása
Bővítményeket is alkalmazhatunk a „Plugin alkalmazása”:
plugin alkalmazása: 'war'Ha hozzá kell adnunk egy közösségi bővítményt, akkor hozzá kell adnunk a külső jarot a build classpath használatához buildscript {} Blokk.
Azután, alkalmazhatjuk a bővítményt a build szkriptekben, decsak bármelyik létező után bővítmények {} Blokk:
buildscript {adattárak {maven {url "//plugins.gradle.org/m2/"}} függőségek {classpath "org.shipkit: shipkit: 0.9.117"}} plugin alkalmazása: "org.shipkit.bintray-release"4. Függőségkezelés
A Gradle nagyon rugalmas függőségkezelő rendszert támogat, kompatibilis a rendelkezésre álló sokféle megközelítéssel.
A Gradle-ban a függőségkezelés legjobb gyakorlatai a verziók, a dinamikus verziók, a verziókonfliktusok megoldása és a tranzitív függőségek kezelése.
4.1. Függőség konfigurálása
A függőségek különböző konfigurációkba vannak csoportosítva. Egy konfigurációnak van neve, és kibővíthetik egymást.
Ha a Java plugint alkalmazzuk, akkor meg is lesz compile, testCompile, futásidejű a függőségeink csoportosítására rendelkezésre álló konfigurációk. A alapértelmezett caz konfiguráció kiterjedfutási idő ”.
4.2. A függőségek deklarálása
Nézzünk meg egy példát néhány függőség (Spring és Hibernate) hozzáadására, többféle módon:
függőségek {compile group: 'org.springframework', név: 'spring-core', verzió: '4.3.5.RELEASE' compile 'org.springframework: spring-core: 4.3.5.RELEASE', 'org.springframework: spring-aop: 4.3.5.RELEASE 'fordítás ([csoport:' org.springframework ', név:' spring-core ', verzió:' 4.3.5.RELEASE '], [csoport:' org.springframework ', név : 'spring-aop', verzió: '4.3.5.RELEASE']) testCompile ('org.hibernate: hibernate-core: 5.2.12.Final') {transitive = true} futásidejű (group: 'org.hibernate' , név: 'hibernate-core', verzió: '5.2.12.Final') {transitive = false}}Különböző konfigurációkban deklaráljuk a függőségeket: összeállítani, testCompile, és futási idő különféle formátumokban.
Néha olyan függőségekre van szükségünk, amelyeknek több lelete van. Ilyen esetekben hozzáadhatunk csak műterméket tartalmazó jelöléseket @ kiterjesztésNév (vagy ext kibővített formában) a kívánt műtárgy letöltéséhez:
futásidejű "org.codehaus.groovy: groovy-all: [email protected]" futásidejű csoport: 'org.codehaus.groovy', név: 'groovy-all', verzió: '2.4.11', ext: 'jar'Itt adtuk hozzá a @befőttes üveg jelölés, hogy csak a jar műtárgyat töltsük le a függőségek nélkül.
Függőségek hozzáadásához bármely helyi fájlhoz használhatunk ilyet:
fájlok fordítása ('libs / joda-time-2.2.jar', 'libs / junit-4.12.jar') compile fileTree (dir: 'libs', tartalmazza: '* .jar')Amikor el akarjuk kerülni a tranzitív függőségeket,megtehetjük konfigurációs szinten vagy függőségi szinten:
konfigurációk {testCompile.exclude module: 'junit'} testCompile ("org.springframework.batch: spring-batch-test: 3.0.7.RELEASE") {modul kizárása: 'junit'}5. Több projekt összeállítása
5.1. Életciklus építése
Az inicializálási szakaszban Gradle meghatározza, hogy mely projektek vesznek részt egy több projekt összeállításában.
Ezt általában megemlítik beállítások.gradle fájl, amely a projekt gyökérkönyvtárában található. Gradle létrehozza a résztvevő projektek példányait is.
A konfigurációs szakaszban az összes létrehozott projektpéldányt a Gradle szolgáltatás igény szerinti konfigurálása alapján konfigurálják.
Ebben a szolgáltatásban csak a szükséges projektek vannak konfigurálva egy adott feladat végrehajtásához. Így a konfigurációs idő nagymértékben lerövidül egy nagy többprojektes összeállítás esetén. Ez a funkció még inkubál.
Végül, a végrehajtási szakaszban a létrehozott és konfigurált feladatok egy részhalmazát hajtják végre. Kódot felvehetünk a beállítások.gradle és épít.gradle fájlokat, hogy érzékeljék ezt a három fázist.
Ban ben beállítások.gradle :
println 'Inicializálási szakaszban.'Ban ben épít.gradle :
println 'A konfigurációs szakaszban.' feladat konfigurálva {println 'A konfigurációs szakaszban is.' } feladat execFirstTest {doLast {println 'A végrehajtási szakaszban.' }} task execSecondTest {doFirst {println 'Először a végrehajtási szakaszban.' } doLast {println 'Végre a végrehajtási szakaszban.' } println 'A konfigurációs szakaszban.' }5.2. Többprojekt-összeállítás létrehozása
Végrehajthatjuk a gradle init parancsot a gyökérmappában csontváz létrehozásához mindkettőhöz beállítások.gradle és épít.gradle fájl.
Az összes általános konfigurációt a root build szkript fogja megtartani:
allprojects {repositories {mavenCentral ()}} alprojektek {version = '1.0'}A beállítási fájlnak tartalmaznia kell a root projekt nevét és az alprojekt nevét:
rootProject.name = A „multi-project-builds” tartalmazza az „üdvözlő könyvtár”, „üdvözlő” elemeketMost meg kell neveznünk pár alprojekt mappát üdvözlő-könyvtár és üdvözlő hogy bemutasson egy többprojektes összeállítást. Minden alprojektnek rendelkeznie kell egy egyedi build szkriptvel az egyes függőségek és egyéb szükséges konfigurációk konfigurálásához.
Ha szeretnénk, ha a miénk lenne üdvözlő projekt függvénye üdvözlő-könyvtár, be kell építenünk a függőséget a üdvözlő:
függőségek {compile project (': greeting-library')}6. A Gradle Wrapper használata
Ha egy Gradle projekt rendelkezik gradlew fájl Linux és gradlew.bat fájlt a Windows rendszerhez, nem kell telepítenünk a Gradle-t a projekt felépítéséhez.
Ha kivégezzük gradlew épít Windows és ./gradlew build Linux alatt a Gradle disztribúció, amelyet a gradlew fájl automatikusan letöltésre kerül.
Ha hozzá szeretnénk adni a Gradle burkolót a projektünkhöz:
gradle wrapper --gradle-verzió 4.2.1A parancsot a projekt gyökerétől kell végrehajtani. Ez létrehozza az összes szükséges fájlt és mappát, hogy a Gradle burkolót a projekthez kösse. A másik módszer ugyanez az, ha hozzáadja a burkoló feladatot a build szkripthez:
feladatburkoló (típus: Wrapper) {gradleVersion = '4.2.1'}Most végre kell hajtanunk a csomagolás feladat és a feladat a projektünket a burkolóhoz köti. mellett gradlew fájlok, a csomagolás mappa a gradle mappát, amely egy korsót és egy tulajdonságfájlt tartalmaz.
Ha át akarunk váltani a Gradle új verziójára, akkor csak egy bejegyzést kell megváltoztatnunk fokozat-burkoló.tulajdonságok.
7. Következtetés
Ebben a cikkben a Gradle-t néztük meg, és láttuk, hogy nagyobb rugalmassággal rendelkezik a többi meglévő buildeszközzel szemben a verziókonfliktusok megoldása és a tranzitív függőségek kezelése szempontjából.
A cikk forráskódja elérhető a GitHub oldalon.
Következő » Ant vs Maven vs Gradle
