streamalism.org

Denne artikkelen er en del av en serie: • Introduksjon til Gradle

• Ant vs Maven vs Gradle

• Skrive egendefinerte Gradle-plugins (nåværende artikkel) • Opprette en fettkrukke i Gradle

1. Introduksjon

Gradle er et veldig populært byggeverktøy, som ofte blir verdsatt for den meget tilpassbare byggeprosessen.

I dag skal vi vise hvordan vi lager egendefinerte Gradle-plugins, som lar oss endre byggeprosessen utover det vi kan oppnå med standardkonfigurasjonen.

2. Plassering av plugin-kilde

Vi kan plassere koden vår på noen få forskjellige steder. Alle har noen fordeler og ulemper.

2.1. Bygg skript

Vi kan ganske enkelt sette kildekoden til pluginet vårt i selve byggeskriptet. Dette vil gi oss automatisk kompilering og inkludering av plugin.

Det er veldig enkelt, men pluginet vårt vil ikke være synlig utenfor build-skriptet. På grunn av det kan vi ikke bruke det i andre byggeskripter.

2.2. BuildSrc Mappe

En annen mulighet vi kan bruke er å plassere kildekoden til pluginet vårt i buildSrc / src / main / java mappe.

Når du kjører Gradle, vil den sjekke om det eksisterer buildSrc mappe. Hvis det eksisterer, vil Gradle automatisk bygge og inkludere pluginet vårt.

Dette vil gi oss muligheten til å dele pluginet vårt mellom forskjellige build-skript, men vi kan fortsatt ikke bruke det i andre prosjekter.

2.3. Frittstående prosjekt

Til slutt kan vi opprette pluginet vårt som et eget prosjekt som gjør pluginet fullt gjenbrukbart i forskjellige prosjekter.

For å bruke det i et eksternt prosjekt, må vi imidlertid pakke det sammen i en jar-fil og legge til et prosjekt.

3. Vår første plugin

La oss starte med det grunnleggende - hver Gradle Plugin må implementere com.gradle.api.Plugin grensesnitt.

Grensesnittet er generisk, så vi kan parametrere det med forskjellige parametertyper. Vanligvis er parametertypen org.gradle.api.Project.

Vi kan imidlertid bruke forskjellige typeparametere slik at plugin-programmet brukes i forskjellige levetidsfaser:

• ved hjelp av org.gradle.api.Settings vil resultere i å bruke pluginet til et innstillingsskript
• ved hjelp av org.gradle.api.Gradle vil resultere i å bruke plugin til et initialiseringsskript

Det enkleste pluginet vi kan lage er en Hei Verden applikasjon:

offentlig klasse GreetingPlugin implementerer Plugin {@Override public void apply (Project project) {project.task ("hallo") .doLast (task -> System.out.println ("Hello Gradle!")); }}

Vi kan nå bruke den ved å legge til en linje i build-skriptet vårt:

bruk plugin: GreetingPlugin

Nå, etter å ha ringt grad hallo, vi får se “Hei Gradle” melding i logger.

4. Plugin-konfigurasjon

De fleste plugins trenger tilgang til en ekstern konfigurasjon fra build-skriptet.

Vi kan gjøre det ved å bruke utvidelsesobjekter:

offentlig klasse GreetingPluginExtension {private String greeter = "Baeldung"; private String message = "Melding fra pluginet!" // standard getters og setters}

La oss nå legge til det nye utvidelsesobjekt til vår plugin-klasse:

@ Override public void apply (Prosjektprosjekt) {GreetingPluginExtension extension = project.getExtensions () .create ("greeting", GreetingPluginExtension.class); project.task ("hallo") .doLast (oppgave -> {System.out.println ("Hello", + extension.getGreeter ()); System.out.println ("Jeg har en melding til deg:" + extension .getMessage ());}); }

Nå, når vi ringer grad hallo, vi ser standardmeldingen definert i vår HilsenPluginExtension.

Men siden vi har opprettet utvidelsen, kan vi bruke en lukking for å gjøre det inne i build-skriptet:

hilsen {greeter = "Stranger" message = "Melding fra byggeskriptet"}

5. Frittstående plugin-prosjekt

For å lage en frittstående Gradle-plugins, må vi gjøre litt mer arbeid.

5.1. Oppsett

For det første må vi importere Gradle API-avhengighet - som er ganske grei:

avhengigheter {kompilere gradleApi ()}

Merk at å gjøre det samme i Maven krever gradle-tooling-api avhengighet - fra Gradle-depotet:

  org.gradle gradle-tooling-api 3.0 org.gradle gradle-core 3.0 gitt repo.gradle.org //repo.gradle.org/gradle/libs-releases-local/ 

5.2. Kabling av plugin

For å la Gradle finne implementeringen av vårt frittstående plugin, må vi opprette egenskapsfilen i src / main / resources / META-INF /gradering-plugins.

Ressursfilen må ha et navn som samsvarer med plugin-ID-en. Så hvis pluginet vårt har en id på org.baeldung.greeting, den nøyaktige banen til filen ville være META-INF / gradle-plugins / org.baeldung.greeting.properties.

Deretter kan vi definere implementeringsklassen til pluginet:

 implementeringsklasse = org.gradle.GreetingPlugin

De implementeringsklasse skal være lik hele pakkenavnet til plugin-klassen vår.

5.3. Opprette plugin-ID

Det er noen regler og konvensjoner som plugin ID må følge i Gradle. De fleste av dem ligner på regler for pakkenavn i Java:

• De kan bare inneholde alfanumeriske tegn, "." og “-“
• ID-en må ha minst en “.” skille domenenavnet fra plugin-navnet
• Navneplasser org.gradle og com.gradleware er begrenset
• En id kan ikke starte eller slutte med “.”
• Ingen to eller flere påfølgende “.” tegn er tillatt

Til slutt er det en konvensjon om at plugin-ID skal være et små og små navn som følger omvendt domenenavnkonvensjon.

Hovedforskjellen mellom Java-pakkenavn og Gradle-plugin-navn er at pakkenavnet vanligvis er mer detaljert enn plugin-ID-en.

5.4. Publiserings-plugin

Når vi vil publisere pluginet vårt for å kunne gjenbruke det i eksterne prosjekter, har vi to måter å oppnå det på.

For det første, vi kan publisere vår plugin JAR til et eksternt lager som Maven eller Eføy.

Alternativt kan vi bruke Gradle Plugin Portal. Dette vil gjøre det mulig for pluginet vårt å få tilgang til et bredt Gradle Community. Mer om publisering av prosjekter i Gradle repository finner du i Gradle Plugin Portal Documentation.

5.5. Java Gradle Development Plugin

Når vi skriver pluginene våre i Java, kan vi dra nytte av Java Gradle Development Plugin.

Dette kompileres automatisk og legges til gradleApi () avhengigheter. Den vil også utføre validering av plugin-metadata som en del av graderkrukke oppgave.

Vi kan legge til plugin ved å legge til følgende blokk i build-skriptet vårt:

plugins {id 'java-gradle-plugin'}

6. Testing av plugins

For å teste at pluginet vårt fungerer som det skal, og at det brukes riktig på Prosjekt, Vi kan bruke org.gradle.testfixtures.ProjectBuilder for å lage en forekomst av Prosjekt.

Vi kan deretter sjekke om programtillegget ble brukt, og at riktige oppgaver er til stede i vårt Prosjekt forekomst. Vi kan bruke standard JUnit tester for å gjøre det:

@Test offentlig ugyldig greetingTest () {Prosjektprosjekt = ProjectBuilder.builder (). Build (); project.getPluginManager (). gjelder ("com.baeldung.greeting"); assertTrue (project.getPluginManager () .hasPlugin ("com.baeldung.greeting")); assertNotNull (project.getTasks (). getByName ("hei")); }

7. Oppsummering

I denne artikkelen har vi vist det grunnleggende om å skrive tilpassede plugins i Gradle. For å gå nærmere inn på opprettelse av plugins, ta en titt på Gradle Documentation.

Og som alltid kan alle kodeeksemplene finnes på Github.

Neste » Lage en feit krukke i Gradle « Forrige Ant vs Maven vs Gradle