Introduksjon til Gradle

Denne artikkelen er en del av en serie: • Introduksjon til Gradle (nåværende artikkel) • Ant vs Maven vs Gradle

• Skrive egendefinerte Gradle-plugins

• Lage en fettkrukke i Gradle

1. Oversikt

Gradle er et Groovy-basert build management system designet spesielt for å bygge Java-baserte prosjekter.

Installasjonsinstruksjoner finner du her.

2. Byggesteiner - Prosjekter og oppgaver

I Gradle består Builds av ett eller flere prosjekter, og hvert prosjekt består av en eller flere oppgaver.

Et prosjekt i Gradle kan montere en krukke, krig eller til og med en glidelås fil.

En oppgave er et enkelt stykke arbeid. Dette kan inkludere kompilering av klasser, eller opprette og publisere Java / webarkiv.

En enkel oppgave kan defineres som:

oppgave hei {doLast {println 'Baeldung'}}

Hvis vi utfører oppgaven ovenfor ved hjelp av gradle -q hei kommando fra samme sted hvor build.gradle bor, bør vi se utdataene i konsollen.

2.1. Oppgaver

Gradles byggeskripter er ingenting annet enn Groovy:

oppgave å senke {doLast {String someString = 'HELLO FRA BAELDUNG' println "Original:" + someString println "Små bokstaver:" + someString.toLowerCase ()}}

Vi kan definere oppgaver som er avhengige av andre oppgaver. Oppgaveavhengighet kan defineres ved å passere dependsOn: taskName argument i en oppgavedefinisjon:

oppgave heiGradle {doLast {println 'Hello Gradle!' }} oppgave fra Baeldung (avhengig av: halloGradle) {doLast {println "Jeg er fra Baeldung"}}

2.2. Legge til atferd i en oppgave

Vi kan definere en oppgave og forbedre den med ytterligere oppførsel:

oppgave helloBaeldung {doLast {println 'Jeg vil bli henrettet andre'}} helloBaeldung.doFirst {println 'Jeg vil bli henrettet først'} helloBaeldung.doLast {println 'Jeg vil bli henrettet tredje'} helloBaeldung {doLast {println 'Jeg vil bli utført fjerde '}}

doFirst og doLast legg til handlinger øverst og nederst på henholdsvis handlingslisten og kan defineres flere ganger i en enkelt oppgave.

2.3. Legge til oppgaveegenskaper

Vi kan også definere egenskaper:

oppgave ourTask {ext.theProperty = "theValue"}

Her setter vi inn "verdien" som eiendommen av vår oppgave oppgave.

3. Administrere programtillegg

Det er to typer plugins i Gradle - manus, og binær.

For å dra nytte av en ekstra funksjonalitet, må hvert plugin gå gjennom to faser: løse og søker.

Løser betyr å finne den riktige versjonen av pluginburken og legge den til i klassesti av prosjektet.

Søker plugins kjøres Plugin.apply (T)på prosjektet.

3.1. Bruker skripttillegg

I aplugin.gradle, vi kan definere en oppgave:

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

Hvis vi vil bruke dette pluginet til prosjektet vårt build.gradle filen, alt vi trenger å gjøre er å legge til denne linjen i vår build.gradle:

gjelder fra: 'aplugin.gradle'

Nå, utfører gradere oppgaver kommandoen skal vise fraPlugin oppgave i oppgavelisten.

3.2. Bruke binære plugins ved hjelp av plugins DSL

I tilfelle å legge til et kjerne-binært plugin, kan vi legge til korte navn eller et plugin-ID:

plugins {id 'applikasjon'}

Nå er det løpe oppgave fra applikasjon plugin skal være tilgjengelig i et prosjekt for å utføre noe kjørbar krukke. For å bruke et community-plugin, må vi nevne et fullstendig plugin-ID:

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

Nå, Shipkit oppgaver skal være tilgjengelig på gradere oppgaver liste.

Begrensningene til pluginene DSL er:

Den støtter ikke Groovy-kode i plugins blokkere
plugins blokken må være toppnivåuttalelsen i prosjektets byggeskripter (bare buildscripts {} blokkering er tillatt før den)
Plugins DSL kan ikke skrives i skript-plugin, settings.gradle fil eller i init-skript

Plugins DSL inkuberer fortsatt. DSL og annen konfigurasjon kan endres i de senere Gradle-versjonene.

3.3. Eldre prosedyre for bruk av plugins

Vi kan også bruke plugins ved hjelp av "Bruk plugin":

bruk plugin: 'war'

Hvis vi trenger å legge til et programtillegg for fellesskapet, må vi legge til den eksterne krukken i byggeklassen med buildscript {} blokkere.

Deretter, vi kan bruke pluginet i build-skriptene, menbare etter eksisterende plugins {} blokkere:

buildscript {repositories {maven {url "//plugins.gradle.org/m2/"}} avhengigheter {classpath "org.shipkit: shipkit: 0.9.117"}} bruk plugin: "org.shipkit.bintray-release"

4. Avhengighetsstyring

Gradle støtter veldig fleksibelt avhengighetsstyringssystem, det er kompatibelt med det store utvalget av tilgjengelige tilnærminger.

Beste fremgangsmåter for avhengighetsadministrasjon i Gradle er versjonering, dynamisk versjonering, løsning av versjonskonflikter og administrering av transitive avhengigheter.

4.1. Avhengighetskonfigurasjon

Avhengigheter er gruppert i forskjellige konfigurasjoner. En konfigurasjon har et navn, og de kan utvide hverandre.

Hvis vi bruker Java-pluginet, vil vi ha det kompilere, testKompilere, kjøretid konfigurasjoner tilgjengelig for gruppering av avhengighet. De standard configuration utvider “kjøretid ”.

4.2. Erklæring om avhengighet

La oss se på et eksempel på å legge til noen avhengigheter (vår og dvalemodus) på flere forskjellige måter:

avhengigheter {kompilere gruppe: 'org.springframework', navn: 'spring-core', versjon: '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 ', versjon:' 4.3.5.RELEASE '], [group:' org.springframework ', navn : 'spring-aop', versjon: '4.3.5.RELEASE']) testCompile ('org.hibernate: hibernate-core: 5.2.12.Final') {transitive = true} runtime (group: 'org.hibernate' , navn: 'hibernate-core', versjon: '5.2.12.Final') {transitive = false}}

Vi erklærer avhengigheter i forskjellige konfigurasjoner: kompilere, testKompilere, og kjøretid i forskjellige formater.

Noen ganger trenger vi avhengigheter som har flere gjenstander. I slike tilfeller kan vi legge til kun-gjenstandsnotasjoner @ utvidelsesnavn (eller ekst i utvidet form) for å laste ned ønsket gjenstand:

kjøretid "org.codehaus.groovy: groovy-all: [email protected]" kjøretidsgruppe: 'org.codehaus.groovy', navn: 'groovy-all', versjon: '2.4.11', ekst: 'jar'

Her la vi til @krukke notasjon for å laste ned bare glassgjenstanden uten avhengighet.

For å legge til avhengigheter til lokale filer, kan vi bruke noe slikt:

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

Når vi vil unngå overgangsavhengigheter,vi kan gjøre det på konfigurasjonsnivå eller på avhengighetsnivå:

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

5. Multi-Project Builds

5.1. Bygg livssyklus

I initialiseringsfasen bestemmer Gradle hvilke prosjekter som skal delta i en flerprosjektbygging.

Dette er vanligvis nevnt i settings.gradle fil, som ligger i prosjektroten. Gradle oppretter også forekomster av deltakende prosjekter.

I konfigurasjonsfasen konfigureres alle opprettet prosjektforekomster basert på Gradle-funksjonskonfigurasjon etter behov.

I denne funksjonen er bare nødvendige prosjekter konfigurert for en bestemt oppgaveutførelse. På denne måten reduseres konfigurasjonstiden sterkt for en stor flerprosjektbygging. Denne funksjonen inkuberer fortsatt.

Endelig, i utførelsesfasen utføres et delsett av oppgaver, opprettet og konfigurert. Vi kan inkludere kode i settings.gradle og build.gradle filer for å oppfatte disse tre fasene.

I settings.gradle :

println 'I initialiseringsfasen.'

I build.gradle :

println 'I konfigurasjonsfasen.' oppgave konfigurert {println 'Også i konfigurasjonsfasen.' } oppgave execFirstTest {doLast {println 'Under kjøringsfasen.' }} oppgave execSecondTest {doFirst {println 'Først under utførelsesfasen.' } doLast {println 'Endelig under utførelsesfasen.' } println 'I konfigurasjonsfasen.' }

5.2. Opprette flerprosjektbygging

Vi kan utføre grad init kommandoen i rotmappen for å lage et skjelett for begge settings.gradle og build.gradle fil.

All vanlig konfigurasjon holdes i root build-skriptet:

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

Innstillingsfilen må inkludere rotprosjektnavn og navn på underprosjekt:

rootProject.name = 'multi-project-builds' inkluderer 'hilsen-bibliotek', 'greeter'

Nå må vi ha et par underprosjektmapper navngitt hilsen-bibliotek og hilsen å ha en demo av et flerprosjektbygg. Hvert delprosjekt må ha et individuelt byggeskript for å konfigurere individuelle avhengigheter og andre nødvendige konfigurasjoner.

Hvis vi vil ha vår hilsen prosjekt avhengig av hilsen-bibliotek, må vi inkludere avhengigheten i build-skriptet til hilsen:

avhengigheter {kompilere prosjekt (': hilsen-bibliotek')}

6. Bruke Gradle Wrapper

Hvis et Gradle-prosjekt har gradlew fil for Linux og gradlew.bat fil for Windows, trenger vi ikke å installere Gradle for å bygge prosjektet.

Hvis vi utfører gradlew bygge i Windows og ./gradlew build i Linux, en Gradle-distribusjon spesifisert i gradlew filen lastes ned automatisk.

Hvis vi vil legge til Gradle-innpakningen i prosjektet vårt:

gradle wrapper - gradle-versjon 4.2.1

Kommandoen må utføres fra roten til prosjektet. Dette vil opprette alle nødvendige filer og mapper for å knytte Gradle-wrapper til prosjektet. Den andre måten å gjøre det samme på er å legge til wrapper-oppgaven i build-skriptet:

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

Nå må vi utføre innpakning oppgave og oppgaven vil knytte prosjektet vårt til innpakningen. Ved siden av gradlew filer, a innpakning mappen genereres inne i gradering mappe som inneholder en krukke og en egenskapsfil.

Hvis vi vil bytte til en ny versjon av Gradle, trenger vi bare å endre en oppføring i gradere-wrapper. eiendommer.

7. Konklusjon

I denne artikkelen så vi på Gradle og så at den har større fleksibilitet i forhold til andre eksisterende byggeverktøy når det gjelder å løse versjonskonflikter og håndtere transitive avhengigheter.

Kildekoden for denne artikkelen er tilgjengelig på GitHub.

Neste » Ant vs Maven vs Gradle

streamalism.org