Afhankelijkheidsbeheer in Gradle

1. Overzicht

In deze zelfstudie kijken we naar het declareren van afhankelijkheden in een Gradle-buildscript. Voor onze voorbeelden gebruiken we Gradle 6.7.

2. Typische structuur

Laten we beginnen met een eenvoudig Gradle-script voor Java-projecten:

plug-ins {id 'java'} opslagplaatsen {mavenCentral ()} afhankelijkheden {implementatie 'org.springframework.boot: spring-boot-starter: 2.3.4.RELEASE' testImplementation 'org.springframework.boot: spring-boot-starter-test : 2.3.4.VRIJGAVE '}

Zoals hierboven te zien is, hebben we drie codeblokken: plug-ins, opslagplaatsen, en afhankelijkheden.

Eerst de plug-ins block vertelt ons dat dit een Java-project is. Ten tweede, de afhankelijkheden block declareert versie 2.3.4.RELEASE van het spring-boot-starter afhankelijkheid die nodig is om de productiebroncode van het project te compileren. Bovendien staat er ook dat de testsuite van het project nodig heeft spring-boot-starter-test compileren.

De Gradle-build haalt alle afhankelijkheden uit de Maven Central-repository, zoals gedefinieerd door de opslagplaatsen blok.

Laten we ons concentreren op hoe we afhankelijkheden kunnen definiëren.

3. Afhankelijkheidsconfiguraties

Er zijn verschillende configuraties waarin we afhankelijkheden kunnen declareren. In dit opzicht kunnen we ervoor kiezen om meer of minder nauwkeurig te zijn, zoals we later zullen zien.

3.1. Afhankelijkheden aangeven

Om te beginnen bestaat de configuratie uit 4 delen:

  • groep - identificatie van een organisatie, bedrijf of project
  • naam - afhankelijkheidsidentificatie
  • versie - degene die we willen importeren
  • classificator - handig om afhankelijkheden met hetzelfde te onderscheiden groep, naam, en versie

We kunnen afhankelijkheden in twee formaten declareren. Het gecontracteerde formaat stelt ons in staat om een ​​afhankelijkheid aan te geven als een Draad:

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

In plaats daarvan stelt het uitgebreide formaat ons in staat om het als een Kaart:

implementatiegroep:'org.springframework.boot', naam: 'spring-boot-starter', versie: '2.3.4.RELEASE'

3.2. Soorten configuratie

Bovendien biedt Gradle veel configuratietypen voor afhankelijkheden:

  • api - gebruikt om de afhankelijkheden expliciet te maken en bloot te stellen in het klassenpad. Als u bijvoorbeeld een bibliotheek implementeert om transparant te zijn voor de bibliotheekconsumenten
  • implementatie- vereist om de productiebroncode te compileren en zijn puur intern. Ze zijn niet zichtbaar buiten de verpakking
  • compileOnly- gebruikt wanneer ze alleen tijdens het compileren moeten worden gedeclareerd, zoals annotaties met alleen bron of annotatieprocessors. Ze verschijnen niet in het runtime-klassenpad of het testklassenpad
  • compileOnlyApi - gebruikt wanneer vereist tijdens het compileren en wanneer ze zichtbaar moeten zijn in het klassenpad voor consumenten
  • looptijdAlleen- gebruikt om afhankelijkheden te declareren die alleen tijdens runtime vereist zijn en niet beschikbaar zijn tijdens het compileren
  • testImplementation- vereist om tests samen te stellen
  • testCompileOnly- alleen vereist tijdens het compileren van de test
  • testRuntimeOnly- alleen vereist tijdens testruntime

We moeten opmerken dat de nieuwste versies van Gradle sommige configuraties afkeuren, zoals compileren, testCompile, looptijd, en testRuntime. Op het moment van schrijven zijn ze nog steeds beschikbaar.

4. Soorten externe afhankelijkheden

Laten we ingaan op de soorten externe afhankelijkheden die we tegenkomen in een Gradle-buildscript.

4.1. Module afhankelijkheden

In feite is de meest gebruikelijke manier om een ​​afhankelijkheid aan te geven, door te verwijzen naar een repository. Een Gradle-repository is een verzameling modules georganiseerd door groep, naam, en versie.

In feite haalt Gradle de afhankelijkheden uit de opgegeven repository binnen het repository blok:

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

4.2. Bestandsafhankelijkheden

Aangezien projecten niet altijd automatisch afhankelijkheidsbeheer gebruiken, organiseren sommige projecten afhankelijkheden als onderdeel van de broncode of het lokale bestandssysteem. We moeten dus de exacte locatie specificeren waar de afhankelijkheden zijn.

Hiervoor kunnen we gebruik maken van bestanden om een ​​afhankelijkheidscollectie op te nemen:

afhankelijkheden {runtimeOnly-bestanden ('libs / lib1.jar', 'libs / lib2.jar')}

Evenzo kunnen we gebruiken filetree om een ​​hiërarchie van op te nemen pot bestanden in een map:

afhankelijkheden {runtimeOnly fileTree ('libs') {include '* .jar'}}

4.3. Projectafhankelijkheden

Omdat het ene project afhankelijk kan zijn van het andere om code te hergebruiken, biedt Gradle ons de mogelijkheid om dat te doen.

Laten we zeggen dat we willen verklaren dat ons project afhankelijk is van de gedeeld project:

 afhankelijkheden {implementatieproject (': shared')} 

4.4. Grijp afhankelijkheden

In bepaalde gevallen, zoals het ontwikkelen van een taak of een plug-in, kunnen we afhankelijkheden definiëren die behoren tot de Gradle-versie die we gebruiken:

afhankelijkheden {implementatie gradleApi ()}

5. buildScript

Zoals we eerder zagen, kunnen we de externe afhankelijkheden van onze broncode en tests binnen het afhankelijkheden blok. Evenzo is het buildScript block stelt ons in staat om de afhankelijkheden van de Gradle-build te declareren, zoals plug-ins van derden en taakklassen. Vooral zonder een buildScript block, kunnen we alleen de kant-en-klare Gradle-functies gebruiken.

Hieronder verklaren we dat we de Spring Boot-plug-in willen gebruiken door deze te downloaden van Maven Central:

buildscript {repositories {mavenCentral ()} afhankelijkheden {classpath 'org.springframework.boot: spring-boot-gradle-plugin: 2.3.4.RELEASE'}} pas plug-in toe: 'org.springframework.boot'

Daarom moeten we de bron specificeren waaruit we externe afhankelijkheden zullen downloaden, omdat er geen standaard is.

Wat hierboven is beschreven, heeft betrekking op oudere versies van Gradle. In plaats daarvan is het in nieuwere versies mogelijk om een ​​beknoptere vorm te gebruiken:

plug-ins {id 'org.springframework.boot' versie '2.3.4.RELEASE'}

6. Conclusie

In dit artikel hebben we gekeken naar Gradle-afhankelijkheden, hoe deze te declareren en de verschillende configuratietypen.

Gezien deze punten is de broncode voor dit artikel beschikbaar op GitHub.


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