streamalism.org

1. Oversikt

I denne opplæringen vil vi se på å erklære avhengigheter i et Gradle build-skript. For eksemplene våre bruker vi Gradle 6.7.

2. Typisk struktur

La oss starte med et enkelt Gradle-skript for Java-prosjekter:

plugins {id 'java'} repositories {mavenCentral ()} avhengigheter {implementering 'org.springframework.boot: spring-boot-starter: 2.3.4.RELEASE' testImplementation 'org.springframework.boot: spring-boot-starter-test : 2.3.4.RELEASE '}

Som det kan sees ovenfor, har vi tre kodeblokker: plugins, repositories, og avhengigheter.

Først, den plugins block forteller oss at dette er et Java-prosjekt. For det andre, den avhengigheter blokk erklærer versjon 2.3.4.UTSLIPP av spring-boot-starter avhengighet som trengs for å kompilere prosjektets produksjonskildekode. I tillegg står det også at prosjektets testpakke trenger vår-støvel-start-test å kompilere.

Gradle-bygningen trekker alle avhengigheter ned fra Maven Central-depotet, som definert av repositories blokkere.

La oss fokusere på hvordan vi kan definere avhengigheter.

3. Avhengighetskonfigurasjoner

Det er forskjellige konfigurasjoner der vi kan erklære avhengigheter. I denne forbindelse kan vi velge å være mer eller mindre presise, som vi vil se senere.

3.1. Hvordan erklære avhengighet

For å starte har konfigurasjonen fire deler:

• gruppe - identifikator for en organisasjon, bedrift eller prosjekt
• Navn - avhengighetsidentifikator
• versjon - den vi vil importere
• klassifikator - nyttig for å skille avhengigheter med det samme gruppe, Navn, og versjon

Vi kan erklære avhengigheter i to formater. Det avtalte formatet lar oss erklære en avhengighet som en String:

implementering 'org.springframework.boot: spring-boot-starter: 2.3.4.RELEASE'

I stedet lar det utvidede formatet oss skrive det som en Kart:

implementeringsgruppe:'org.springframework.boot', navn: 'spring-boot-starter', versjon: '2.3.4.RELEASE'

3.2. Typer konfigurasjon

Videre gir Gradle mange avhengighetskonfigurasjonstyper:

• api - brukes til å gjøre avhengighetene eksplisitte og avsløre dem i klassestien. For eksempel når du implementerer et bibliotek for å være gjennomsiktig for bibliotekets forbrukere
• gjennomføring- kreves for å kompilere kildekoden for produksjonen og er rent internt. De blir ikke utsatt utenfor pakken
• kompilere bare- brukes når de bare må erklæres ved kompileringstid, for eksempel kun kilde-merknader eller merkeprosessorer. De vises ikke i løpetidskursstien eller testkursstien
• compileOnlyApi - brukes når det kreves på kompileringstidspunktet og når de trenger å være synlige i klassestien for forbrukere
• kjøretid bare- brukes til å erklære avhengigheter som bare kreves ved kjøretid og som ikke er tilgjengelige på kompileringstidspunktet
• testImplementering- kreves for å utarbeide tester
• testCompileOnly- kreves bare ved testkompileringstid
• testRuntimeOnly- kreves bare ved testkjøring

Vi bør merke oss at de siste versjonene av Gradle avskriver noen konfigurasjoner som kompilere, testKompilere, kjøretid, og testRuntime. I skrivende stund er de fremdeles tilgjengelige.

4. Typer av eksterne avhengigheter

La oss fordype oss i hvilke typer eksterne avhengigheter vi møter i et Gradle build-skript.

4.1. Modulavhengigheter

I utgangspunktet er den vanligste måten å erklære en avhengighet på ved å referere til et depot. Et Gradle repository er en samling moduler organisert av gruppe, Navn, og versjon.

Faktisk trekker Gradle ned avhengighetene fra det angitte depotet inne i oppbevaringssted blokkere:

repositories {mavenCentral ()} avhengigheter {implementering 'org.springframework.boot: spring-boot-starter: 2.3.4.RELEASE'}

4.2. Filavhengighet

Gitt at prosjekter ikke alltid bruker automatisk avhengighetsadministrasjon, organiserer noen prosjekter avhengigheter som en del av kildekoden eller det lokale filsystemet. Derfor må vi spesifisere den nøyaktige plasseringen der avhengighetene er.

For dette formålet kan vi bruke filer å inkludere en avhengighetssamling:

avhengigheter {runtimeOnly files ('libs / lib1.jar', 'libs / lib2.jar')}

På samme måte kan vi bruke filetree å inkludere et hierarki av krukke filer i en katalog:

avhengigheter {runtimeOnly fileTree ('libs') {inkluderer '* .jar'}}

4.3. Prosjektavhengigheter

Siden et prosjekt kan stole på et annet for å gjenbruke kode, gir Gradle oss muligheten til å gjøre det.

La oss si at vi vil erklære at prosjektet vårt avhenger av delt prosjekt:

 avhengigheter {implementeringsprosjekt (': delt')} 

4.4. Gradle Avhengigheter

I visse tilfeller, for eksempel å utvikle en oppgave eller et plugin, kan vi definere avhengigheter som hører til Gradle-versjonen vi bruker:

avhengigheter {implementering gradleApi ()}

5. buildScript

Som vi så før, kan vi erklære de eksterne avhengighetene til kildekoden og tester inne i avhengigheter blokkere. Tilsvarende buildScript block tillater oss å erklære Gradle builds avhengigheter, for eksempel tredjeparts plugins og oppgaveklasser. Spesielt uten en buildScript kan vi bare bruke Gradle out-of-the-box-funksjoner.

Nedenfor erklærer vi at vi vil bruke Spring Boot-pluginet ved å laste det ned fra Maven Central:

buildscript {repositories {mavenCentral ()} avhengigheter {classpath 'org.springframework.boot: spring-boot-gradle-plugin: 2.3.4.RELEASE'}} bruk plugin: 'org.springframework.boot'

Derfor må vi spesifisere kilden som vi vil laste ned eksterne avhengigheter fra, fordi det ikke er en standard.

Det som er beskrevet ovenfor er relatert til eldre versjoner av Gradle. I stedet for, i nyere versjoner, er det mulig å bruke en mer kortfattet form:

plugins {id 'org.springframework.boot' versjon '2.3.4.RELEASE'}

6. Konklusjon

I denne artikkelen så vi på Gradle-avhengigheter, hvordan deklareres og forskjellige konfigurasjonstyper.

Gitt disse punktene, er kildekoden for denne artikkelen tilgjengelig på GitHub.