streamalism.org

Dit artikel maakt deel uit van een serie: • Inleiding tot Gradle (huidig ​​artikel) • Ant vs Maven vs Gradle

• Aangepaste Gradle-plug-ins schrijven

• Een vetpot maken in Gradle

1. Overzicht

Gradle is een op Groovy gebaseerd buildbeheersysteem dat speciaal is ontworpen voor het bouwen van op Java gebaseerde projecten.

Installatie-instructies zijn hier te vinden.

2. Bouwstenen - Projecten en taken

In Gradle bestaat Builds uit een of meer projecten en elk project bestaat uit een of meer taken.

Een project in Gradle kan een pot, oorlog of zelfs een zip het dossier.

Een taak is een enkel stuk werk. Dit kan het compileren van klassen zijn, of het maken en publiceren van Java / webarchieven.

Een eenvoudige taak kan worden gedefinieerd als:

taak hallo {doLast {println 'Baeldung'}}

Als we bovenstaande taak uitvoeren met gradle -q hallo commando vanaf dezelfde locatie waar build.gradle zich bevindt, zouden we de uitvoer in de console moeten zien.

2.1. Taken

De build-scripts van Gradle zijn niets anders dan Groovy:

task toLower {doLast {String someString = 'HALLO VAN BAELDUNG' println "Origineel:" + someString println "Kleine letters:" + someString.toLowerCase ()}}

We kunnen taken definiëren die afhankelijk zijn van andere taken. Taakafhankelijkheid kan worden gedefinieerd door het afhankelijk van: taskName argument in een taakdefinitie:

taak halloGradle {doLast {println 'Hallo Gradle!' }} taak van Baeldung (afhankelijk van: helloGradle) {doLast {println "I'm from Baeldung"}}

2.2. Gedrag aan een taak toevoegen

We kunnen een taak definiëren en deze verbeteren met wat aanvullend gedrag:

taak halloBaeldung {doLast {println 'Ik zal als tweede worden geëxecuteerd'}} halloBaeldung.doFirst {println 'Ik zal als eerste worden geëxecuteerd'} halloBaeldung.doLast {println 'Ik zal als derde worden geëxecuteerd'} halloBaeldung {doLast {println 'Ik zal zijn vierde uitgevoerd '}}

doe eerst en doLast acties toevoegen aan de boven- en onderkant van de actielijst, respectievelijk, en kan meerdere keren in een enkele taak worden gedefinieerd.

2.3. Taakeigenschappen toevoegen

We kunnen ook eigenschappen definiëren:

taak ourTask {ext.theProperty = "theValue"} 

Hier zitten we "de waarde" net zo het eigendom van de onze taak taak.

3. Plug-ins beheren

Er zijn twee soorten plug-ins in Gradle - script, en binair.

Om te profiteren van een extra functionaliteit, moet elke plug-in twee fasen doorlopen: oplossen en toepassen.

Oplossen betekent het vinden van de juiste versie van de plugin-jar en die toevoegen aan de klassenpad van het project.

Toepassen plug-ins wordt uitgevoerd Plugin.apply (T)aan het project.

3.1. Script-plug-ins toepassen

In de aplugin.gradle, we kunnen een taak definiëren:

task fromPlugin {doLast {println "I'm from plugin"}}

Als we deze plug-in op ons project willen toepassen build.gradle bestand, hoeven we alleen maar deze regel toe te voegen aan ons build.gradle:

toepassen vanaf: 'aplugin.gradle' 

Nu uitvoeren geleidelijke taken commando zou het fromPlugin taak in de takenlijst.

3.2. Binaire plug-ins toepassen met DSL-plug-ins

In het geval van het toevoegen van een binaire kernplug-in, kunnen we korte namen of een plug-in-ID toevoegen:

plug-ins {id 'applicatie'}

Nu de rennen taak van toepassing plug-in moet beschikbaar zijn in een project om een uitvoerbaar pot. Om een ​​community-plug-in toe te passen, moeten we een volledig gekwalificeerde plug-in-ID vermelden:

plug-ins {id "org.shipkit.bintray" versie "0.9.116"}

Nu, Shipkit taken moeten beschikbaar zijn op geleidelijke taken lijst.

De beperkingen van de plug-ins DSL zijn:

• Het ondersteunt geen Groovy-code in het plug-ins blok
• plug-ins block moet de instructie op het hoogste niveau zijn in de build-scripts van het project (alleen buildscripts {} blok is toegestaan ​​ervoor)
• Plug-ins DSL kan niet worden geschreven in scriptplug-in, settings.gradle bestand of in init-scripts

Plug-ins DSL is nog aan het broeden. De DSL en andere configuratie kunnen veranderen in de latere Gradle-versies.

3.3. Legacy-procedure voor het toepassen van plug-ins

We kunnen ook plug-ins toepassen met behulp van de "Plug-in toepassen":

pas plug-in toe: 'oorlog'

Als we een community-plug-in moeten toevoegen, moeten we de externe jar aan het build classpath toevoegen met buildscript {} blok.

Dan, we kunnen de plug-in toepassen in de build-scripts maarpas na bestaande plug-ins {} blok:

buildscript {repositories {maven {url "//plugins.gradle.org/m2/"}} afhankelijkheden {classpath "org.shipkit: shipkit: 0.9.117"}} pas plug-in toe: "org.shipkit.bintray-release"

4. Afhankelijkheidsbeheer

Gradle ondersteunt een zeer flexibel afhankelijkheidsbeheersysteem, het is compatibel met de grote verscheidenheid aan beschikbare benaderingen.

Best practices voor afhankelijkheidsbeheer in Gradle zijn versiebeheer, dynamisch versiebeheer, versieconflicten oplossen en transitieve afhankelijkheden beheren.

4.1. Afhankelijkheidsconfiguratie

Afhankelijkheden zijn gegroepeerd in verschillende configuraties. Een configuratie heeft een naam en ze kunnen elkaar uitbreiden.

Als we de Java-plug-in toepassen, hebben we compileren, testCompile, runtime configuraties beschikbaar voor het groeperen van onze afhankelijkheden. De standaard configuration verlengt “looptijd ”.

4.2. Afhankelijkheden declareren

Laten we eens kijken naar een voorbeeld van het toevoegen van enkele afhankelijkheden (lente en slaapstand) op verschillende manieren:

afhankelijkheden {compileer groep: 'org.springframework', naam: 'spring-core', versie: '4.3.5.RELEASE' compile 'org.springframework: spring-core: 4.3.5.RELEASE', 'org.springframework: spring-aop: 4.3.5.RELEASE 'compileren ([groep:' org.springframework ', naam:' spring-core ', versie:' 4.3.5.RELEASE '], [groep:' org.springframework ', naam : 'spring-aop', versie: '4.3.5.RELEASE']) testCompile ('org.hibernate: hibernate-core: 5.2.12.Final') {transitive = true} runtime (groep: 'org.hibernate') , naam: 'hibernate-core', versie: '5.2.12.Final') {transitief = false}}

We verklaren afhankelijkheden in verschillende configuraties: compileren, testCompile, en looptijd in verschillende formaten.

Soms hebben we afhankelijkheden nodig die meerdere artefacten hebben. In dergelijke gevallen kunnen we notaties met alleen artefacten toevoegen @extensieNaam (of ext in de uitgebreide vorm) om het gewenste artefact te downloaden:

runtime "org.codehaus.groovy: groovy-all: [email protected]" runtime-groep: 'org.codehaus.groovy', naam: 'groovy-all', versie: '2.4.11', ext: 'jar'

Hier hebben we het @pot notatie om alleen het jar-artefact te downloaden zonder de afhankelijkheden.

Om afhankelijkheden aan lokale bestanden toe te voegen, kunnen we zoiets als dit gebruiken:

compileer bestanden ('libs / joda-time-2.2.jar', 'libs / junit-4.12.jar') compileer fileTree (dir: 'libs', include: '* .jar')

Als we transitieve afhankelijkheden willen vermijden,we kunnen het doen op configuratieniveau of op afhankelijkheidsniveau:

configuraties {testCompile.exclude module: 'junit'} testCompile ("org.springframework.batch: spring-batch-test: 3.0.7.RELEASE") {module uitsluiten: 'junit'}

5. Meerdere projecten bouwen

5.1. Bouw levenscyclus

In de initialisatiefase bepaalt Gradle welke projecten zullen deelnemen aan een build met meerdere projecten.

Dit wordt meestal vermeld in settings.gradle bestand, dat zich in de root van het project bevindt. Gradle maakt ook exemplaren van de deelnemende projecten.

In de configuratiefase worden alle aangemaakte projectinstanties geconfigureerd op basis van Gradle-functieconfiguratie op aanvraag.

In deze functie worden alleen vereiste projecten geconfigureerd voor het uitvoeren van een specifieke taak. Op deze manier wordt de configuratietijd sterk verkort voor een grote build met meerdere projecten. Deze functie is nog aan het broeden.

Tenslotte, in de uitvoeringsfase wordt een subset van gemaakte en geconfigureerde taken uitgevoerd. We kunnen code opnemen in het settings.gradle en build.gradle bestanden om deze drie fasen waar te nemen.

In settings.gradle :

println 'In initialisatiefase.'

In build.gradle :

println 'In configuratiefase.' taak geconfigureerd {println 'Ook in de configuratiefase.' } task execFirstTest {doLast {println 'Tijdens de uitvoeringsfase.' }} task execSecondTest {doFirst {println 'In eerste instantie tijdens de uitvoeringsfase.' } doLast {println 'Eindelijk tijdens de uitvoeringsfase.' } println 'In configuratiefase.' }

5.2. Creëren van multi-project build

We kunnen het gradle init commando in de hoofdmap om een ​​skelet voor beide te maken settings.gradle en build.gradle het dossier.

Alle gebruikelijke configuraties worden bewaard in het root-buildscript:

allprojects {repositories {mavenCentral ()}} subprojecten {version = '1.0'}

Het instellingenbestand moet de rootprojectnaam en de subprojectnaam bevatten:

rootProject.name = 'multi-project-builds' inclusief 'begroetingsbibliotheek', 'greeter'

Nu hebben we een aantal subprojectmappen nodig begroeting-bibliotheek en begroeter om een ​​demo te krijgen van een build met meerdere projecten. Elk subproject heeft een individueel build-script nodig om hun individuele afhankelijkheden en andere noodzakelijke configuraties te configureren.

Als we onze willen hebben begroeter project afhankelijk van de begroeting-bibliotheek, moeten we de afhankelijkheid opnemen in het build-script van begroeter:

afhankelijkheden {compile project (': greeting-library')}

6. Gradle Wrapper gebruiken

Als een Gradle-project heeft gradlew bestand voor Linux en gradlew.bat bestand voor Windows, hoeven we Gradle niet te installeren om het project te bouwen.

Als we executeren gradlew bouwen in Windows en ./gradlew build in Linux, een Gradle-distributie gespecificeerd in gradlew bestand wordt automatisch gedownload.

Als we de Gradle-wrapper aan ons project willen toevoegen:

gradle wrapper --gradle-versie 4.2.1

De opdracht moet worden uitgevoerd vanuit de root van het project. Hiermee worden alle benodigde bestanden en mappen gemaakt om Gradle-wrapper aan het project te binden. De andere manier om hetzelfde te doen is door de wrapper-taak toe te voegen aan het build-script:

taak wrapper (type: Wrapper) {gradleVersion = '4.2.1'}

Nu moeten we het wikkel taak en de taak zal ons project aan de verpakking binden. naast de gradlew bestanden, een wikkel map wordt gegenereerd in het gradle map met een jar en een eigenschappenbestand.

Als we willen overschakelen naar een nieuwe versie van Gradle, hoeven we alleen een item te wijzigen in gradueelwrapper.properties.

7. Conclusie

In dit artikel hebben we Gradle bekeken en gezien dat het meer flexibiliteit heeft dan andere bestaande build-tools wat betreft het oplossen van versieconflicten en het beheren van transitieve afhankelijkheden.

De broncode voor dit artikel is beschikbaar op GitHub.

De volgende » Ant vs Maven vs Gradle