Afhængighedsstyring i Gradle

1. Oversigt

I denne vejledning ser vi på at erklære afhængigheder i et Gradle build-script. For vores eksempler bruger vi Gradle 6.7.

2. Typisk struktur

Lad os starte med et simpelt Gradle-script til Java-projekter:

plugins {id 'java'} repositories {mavenCentral ()} afhængigheder {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 ses ovenfor, har vi tre kodeblokke: plugins, arkiver, og afhængigheder.

Først plugins block fortæller os, at dette er et Java-projekt. For det andet, den afhængigheder blok erklærer version 2.3.4.UDGIVELSE af spring-boot-starter afhængighed, der er nødvendig for at kompilere projektets produktionskildekode. Derudover står det også, at projektets testpakke har brug for spring-boot-starter-test at kompilere.

Gradle-build trækker alle afhængigheder ned fra Maven Central-arkivet, som defineret af opbevaringssteder blok.

Lad os fokusere på, hvordan vi kan definere afhængigheder.

3. Afhængighedskonfigurationer

Der er forskellige konfigurationer, hvor vi kan erklære afhængigheder. I denne henseende kan vi vælge at være mere eller mindre præcise, som vi senere vil se.

3.1. Sådan erklæres afhængighed

For at starte har konfigurationen fire dele:

  • gruppe - identifikator for en organisation, virksomhed eller projekt
  • navn - afhængighedsidentifikator
  • version - den, vi vil importere
  • klassifikator - nyttigt at skelne afhængigheder med det samme gruppe, navnog version

Vi kan erklære afhængigheder i to formater. Det kontraktformede format giver os mulighed for at erklære en afhængighed som en Snor:

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

I stedet giver det udvidede format os mulighed for at skrive det som en Kort:

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

3.2. Konfigurationstyper

Desuden giver Gradle mange afhængighedskonfigurationstyper:

  • api - bruges til at gøre afhængigheder eksplicitte og eksponere dem i klassestien. For eksempel når man implementerer et bibliotek for at være gennemsigtigt for bibliotekets forbrugere
  • implementering- kræves for at kompilere produktionskildekoden og er rent interne. De udsættes ikke for uden for pakken
  • kompilérKun- bruges, når de kun skal erklæres ved kompileringstid, såsom kun kilde-annoteringer eller annoteringsprocessorer. De vises ikke i løbetidsklassestien eller testklassestien
  • compileOnlyApi - bruges når det kræves på kompileringstidspunktet, og når de skal være synlige på klassestien for forbrugerne
  • runtimeKun- bruges til at erklære afhængigheder, der kun kræves ved kørsel og ikke er tilgængelige på kompileringstidspunktet
  • testImplementering- kræves for at udarbejde prøver
  • testKompilér kun- kræves kun ved testkompileringstidspunktet
  • testRuntimeOnly- kræves kun ved testkørselstid

Vi skal bemærke, at de nyeste versioner af Gradle forælder nogle konfigurationer som f.eks udarbejde, testKompilér, runtime, og testRuntime. I skrivende stund er de stadig tilgængelige.

4. Typer af eksterne afhængigheder

Lad os dykke ned i de typer eksterne afhængigheder, vi støder på i et Gradle-build-script.

4.1. Modulafhængigheder

Dybest set er den mest almindelige måde at erklære en afhængighed på ved at henvise til et lager. Et Gradle-arkiv er en samling moduler organiseret af gruppe, navnog version.

Faktisk trækker Gradle afhængighederne fra det angivne lager inde i lager blok:

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

4.2. Filafhængighed

Da projekter ikke altid bruger automatisk afhængighedsstyring, organiserer nogle projekter afhængigheder som en del af kildekoden eller det lokale filsystem. Derfor skal vi specificere den nøjagtige placering, hvor afhængighederne er.

Til dette formål kan vi bruge filer at inkludere en afhængighedsindsamling:

afhængigheder {runtimeOnly filer ('libs / lib1.jar', 'libs / lib2.jar')}

På samme måde kan vi bruge filetræ at inkludere et hierarki af krukke filer i et bibliotek:

afhængigheder {runtimeOnly fileTree ('libs') {inkluderer '* .jar'}}

4.3. Projektafhængigheder

Da et projekt kan afhænge af et andet for at genbruge kode, giver Gradle os muligheden for at gøre det.

Lad os sige, at vi vil erklære, at vores projekt afhænger af delt projekt:

 afhængigheder {implementeringsprojekt (': delt')} 

4.4. Gradueafhængigheder

I visse tilfælde, såsom at udvikle en opgave eller et plugin, kan vi definere afhængigheder, der hører til Gradle-versionen, vi bruger:

afhængigheder {implementering gradleApi ()}

5. buildScript

Som vi så før, kan vi erklære de eksterne afhængigheder af vores kildekode og tests inde i afhængigheder blok. Tilsvarende er buildScript blok giver os mulighed for at erklære Gradle builds afhængigheder, såsom tredjeparts plugins og opgaveklasser. Især uden en buildScript blokere, kan vi kun bruge Gradle out-of-the-box-funktioner.

Nedenfor erklærer vi, at vi vil bruge Spring Boot-pluginet ved at downloade det fra Maven Central:

buildscript {repositories {mavenCentral ()} afhængigheder {classpath 'org.springframework.boot: spring-boot-gradle-plugin: 2.3.4.RELEASE'}} anvend plugin: 'org.springframework.boot'

Derfor er vi nødt til at specificere den kilde, hvorfra vi downloader eksterne afhængigheder, fordi der ikke er en standardkilde.

Det, der er beskrevet ovenfor, er relateret til ældre versioner af Gradle. I stedet for i nyere versioner er det muligt at bruge en mere kortfattet form:

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

6. Konklusion

I denne artikel så vi på Gradle-afhængigheder, hvordan man erklærer dem og de forskellige konfigurationstyper.

I betragtning af disse punkter er kildekoden til denne artikel tilgængelig på GitHub.


$config[zx-auto] not found$config[zx-overlay] not found