streamalism.org

Denne artikel er en del af en serie: • Introduktion til Gradle (nuværende artikel) • Ant vs Maven vs Gradle

• Skrivning af brugerdefinerede Gradle-plugins

• Oprettelse af en fed krukke i Gradle

1. Oversigt

Gradle er et Groovy-baseret build management system designet specielt til opbygning af Java-baserede projekter.

Installationsvejledning kan findes her.

2. Byggesten - Projekter og opgaver

I Gradle består Builds af et eller flere projekter, og hvert projekt består af en eller flere opgaver.

Et projekt i Gradle kan samle en krukke, krig eller endda en lynlås fil.

En opgave er et enkelt stykke arbejde. Dette kan omfatte kompilering af klasser eller oprettelse og udgivelse af Java / webarkiver.

En simpel opgave kan defineres som:

opgave hej {doLast {println 'Baeldung'}}

Hvis vi udfører ovenstående opgave ved hjælp af gradle -q hej kommando fra samme sted hvor build.gradle bor, skal vi se output i konsollen.

2.1. Opgaver

Gradles build-scripts er intet andet end Groovy:

opgave toLower {doLast {String someString = 'HELLO FRA BAELDUNG' println "Original:" + someString println "Små bogstaver:" + someString.toLowerCase ()}}

Vi kan definere opgaver, der afhænger af andre opgaver. Opgaveafhængighed kan defineres ved at videregive dependsOn: taskName argument i en opgavedefinition:

opgave hejGradle {doLast {println 'Hello Gradle!' }} opgave fra Baeldung (afhænger af: helloGradle) {doLast {println "Jeg er fra Baeldung"}}

2.2. Tilføjelse af adfærd til en opgave

Vi kan definere en opgave og forbedre den med yderligere adfærd:

opgave helloBaeldung {doLast {println 'Jeg vil blive udført andet'}} helloBaeldung.doFirst {println 'Jeg vil blive udført først'} helloBaeldung.doLast {println 'Jeg vil blive udført tredje'} helloBaeldung {doLast {println 'Jeg vil blive udført fjerde '}}

doFirst og doLast tilføj handlinger øverst og nederst på henholdsvis handlingslisten og kan defineres flere gange i en enkelt opgave.

2.3. Tilføjelse af opgaveegenskaber

Vi kan også definere egenskaber:

opgave ourTask {ext.theProperty = "theValue"} 

Her sætter vi os "værdien" som ejendommen af vores opgave opgave.

3. Administration af plugins

Der er to typer plugins i Gradle - manuskript, og binær.

For at drage fordel af en ekstra funktionalitet skal hvert plugin gennemgå to faser: løser og ansøger.

Løser betyder at finde den rigtige version af pluginburken og føje den til klassesti af projektet.

Anvender plugins udføres Plugin.apply (T)på projektet.

3.1. Anvendelse af script-plugins

I aplugin.gradle, vi kan definere en opgave:

opgave fra Plugin {doLast {println "Jeg er fra plugin"}}

Hvis vi vil anvende dette plugin til vores projekt build.gradle fil, alt hvad vi skal gøre er at tilføje denne linje til vores build.gradle:

ansøg fra: 'aplugin.gradle' 

Nu udfører gradle opgaver kommandoen skal vise fra Plugin opgave i opgavelisten.

3.2. Anvendelse af binære plugins ved hjælp af plugins DSL

I tilfælde af tilføjelse af et kernebinært plugin kan vi tilføje korte navne eller et plugin-id:

plugins {id 'applikation'}

Nu er det løb opgave fra Ansøgning plugin skal være tilgængeligt i et projekt for at udføre ethvert kører krukke. For at anvende et community-plugin skal vi nævne et fuldt kvalificeret plugin-id:

plugins {id "org.shipkit.bintray" version "0.9.116"}

Nu, Shipkit opgaver skal være tilgængelige den gradle opgaver liste.

Begrænsningerne for plugins DSL er:

• Det understøtter ikke Groovy-kode inde i plugins blok
• plugins blok skal være det øverste niveau erklæring i projektets build-scripts (kun buildscripts {} blok er tilladt før den)
• Plugins DSL kan ikke skrives i scripts-plugin, settings.gradle fil eller i init-scripts

Plugins DSL inkuberer stadig. DSL og anden konfiguration kan ændre sig i de senere Gradle-versioner.

3.3. Ældre procedure til anvendelse af plugins

Vi kan også anvende plugins ved hjælp af "Anvend plugin":

anvend plugin: 'krig'

Hvis vi har brug for at tilføje et community-plugin, skal vi tilføje den eksterne jar til build-klassestien ved hjælp af buildscript {} blok.

Derefter, vi kan anvende pluginet i build-scripts, menkun efter nogen eksisterende plugins {} blok:

buildscript {repositories {maven {url "//plugins.gradle.org/m2/"}} afhængigheder {classpath "org.shipkit: shipkit: 0.9.117"}} anvend plugin: "org.shipkit.bintray-release"

4. Afhængighedsstyring

Gradle understøtter meget fleksibelt afhængighedsstyringssystem, det er kompatibelt med de mange forskellige tilgængelige tilgange.

Bedste fremgangsmåder til afhængighedsstyring i Gradle er versionering, dynamisk versioning, løsning af versionskonflikter og styring af transitive afhængigheder.

4.1. Afhængighedskonfiguration

Afhængigheder er grupperet i forskellige konfigurationer. En konfiguration har et navn, og de kan udvide hinanden.

Hvis vi anvender Java-pluginet, har vi det compile, testCompile, runtime konfigurationer tilgængelige til gruppering af vores afhængigheder. Det standard configuration udvider “runtime ”.

4.2. Erklæring om afhængigheder

Lad os se på et eksempel på tilføjelse af nogle afhængigheder (forår og dvale) på flere forskellige måder:

afhængigheder {kompilér gruppe: 'org.springframework', navn: 'spring-core', version: '4.3.5.RELEASE' compile 'org.springframework: spring-core: 4.3.5.RELEASE', 'org.springframework: spring-aop: 4.3.5.RELEASE 'kompilere ([gruppe:' org.springframework ', navn:' spring-core ', version:' 4.3.5.RELEASE '], [group:' org.springframework ', navn : 'spring-aop', version: '4.3.5.RELEASE']) testCompile ('org.hibernate: hibernate-core: 5.2.12.Final') {transitive = true} runtime (gruppe: 'org.hibernate' , navn: 'hibernate-core', version: '5.2.12.Final') {transitive = false}}

Vi erklærer afhængigheder i forskellige konfigurationer: udarbejde, testKompilérog runtime i forskellige formater.

Nogle gange har vi brug for afhængigheder, der har flere artefakter. I sådanne tilfælde kan vi tilføje kun artefaktnotationer @ udvidelsesnavn (eller ekst i den udvidede form) for at downloade den ønskede artefakt:

runtime "org.codehaus.groovy: groovy-all: [email protected]" runtime group: 'org.codehaus.groovy', navn: 'groovy-all', version: '2.4.11', ekst: 'jar'

Her tilføjede vi @krukke notation for kun at downloade jar-artefakten uden afhængighederne.

For at tilføje afhængigheder til lokale filer kan vi bruge noget som dette:

kompilere filer ('libs / joda-time-2.2.jar', 'libs / junit-4.12.jar') kompilere fileTree (dir: 'libs', inkluderer: '* .jar')

Når vi vil undgå forbigående afhængigheder,vi kan gøre det på konfigurationsniveau eller afhængighedsniveau:

konfigurationer {testCompile.exclude-modul: 'junit'} testCompile ("org.springframework.batch: spring-batch-test: 3.0.7. RELEASE") {ekskluder modul: 'junit'}

5. Multi-Project Builds

5.1. Byg livscyklus

I initialiseringsfasen bestemmer Gradle, hvilke projekter der skal deltage i en flerprojektopbygning.

Dette er normalt nævnt i settings.gradle fil, som er placeret i projektets rod. Gradle opretter også forekomster af de deltagende projekter.

I konfigurationsfasen konfigureres alle oprettede projektforekomster baseret på Gradle-funktionskonfiguration efter behov.

I denne funktion er kun nødvendige projekter konfigureret til en bestemt opgaveudførelse. På denne måde er konfigurationstiden stærkt reduceret for en stor multi-projektbygning. Denne funktion inkuberer stadig.

Langt om længe, i udførelsesfasen udføres et undersæt af opgaver, der er oprettet og konfigureret. Vi kan medtage kode i settings.gradle og build.gradle filer for at opfatte disse tre faser.

I settings.gradle :

println 'I initialiseringsfasen.'

I build.gradle :

println 'I konfigurationsfasen.' opgave konfigureret {println 'Også i konfigurationsfasen.' } opgave execFirstTest {doLast {println 'Under udførelsesfasen.' }} opgave execSecondTest {doFirst {println 'Først under udførelsesfasen.' } doLast {println 'Endelig under udførelsesfasen.' } println 'I konfigurationsfasen.' }

5.2. Oprettelse af Multi-Project Build

Vi kan udføre gradering init kommando i rodmappen for at oprette et skelet til begge settings.gradle og build.gradle fil.

Al almindelig konfiguration opbevares i root build-scriptet:

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

Indstillingsfilen skal indeholde rodprojektnavn og underprojektnavn:

rootProject.name = 'multi-project-builds' inkluderer 'greeting-library', 'greeter'

Nu skal vi have et par underprojektmapper navngivet hilsen-bibliotek og hilsen at have en demo af et multi-projekt build. Hvert delprojekt skal have et individuelt build-script for at konfigurere deres individuelle afhængigheder og andre nødvendige konfigurationer.

Hvis vi gerne vil have vores hilsen projekt afhængig af hilsen-bibliotek, skal vi medtage afhængigheden i build scriptet til hilsen:

afhængigheder {kompilér projekt (': hilsen-bibliotek')}

6. Brug af Gradle Wrapper

Hvis et Gradle-projekt har gradlew fil til Linux og gradlew.bat fil til Windows, behøver vi ikke installere Gradle for at opbygge projektet.

Hvis vi udfører gradlew bygge i Windows og ./gradlew build i Linux, en Gradle-distribution specificeret i gradlew filen downloades automatisk.

Hvis vi gerne vil tilføje Gradle-indpakningen til vores projekt:

gradle wrapper - gradle-version 4.2.1

Kommandoen skal udføres fra projektets rod. Dette opretter alle nødvendige filer og mapper til at binde Gradle-indpakning til projektet. Den anden måde at gøre det samme på er at tilføje wrapper-opgaven til build-scriptet:

opgaveindpakning (type: Wrapper) {gradleVersion = '4.2.1'}

Nu er vi nødt til at udføre indpakning opgave, og opgaven binder vores projekt til indpakningen. udover det gradlew filer, a indpakning mappen genereres inde i gradle mappe, der indeholder en krukke og en egenskabsfil.

Hvis vi vil skifte til en ny version af Gradle, behøver vi kun ændre en post i gradle-indpakning. ejendomme.

7. Konklusion

I denne artikel så vi på Gradle og så, at den har større fleksibilitet i forhold til andre eksisterende buildværktøjer med hensyn til løsning af versionskonflikter og styring af transitive afhængigheder.

Kildekoden til denne artikel er tilgængelig på GitHub.

Næste » Ant vs Maven vs Gradle