streamalism.org

Denne artikel er en del af en serie: • Introduktion til Gradle

• Ant vs Maven vs Gradle

• Skrivning af brugerdefinerede Gradle-plugins (nuværende artikel) • Oprettelse af en Fat Jar i Gradle

1. Introduktion

Gradle er et meget populært byggeværktøj, som ofte værdsættes for den meget tilpasselige byggeproces.

I dag skal vi vise, hvordan vi opretter tilpassede Gradle-plugins, der giver os mulighed for at ændre byggeprocessen ud over hvad vi kan opnå med standardkonfigurationen.

2. Placering af pluginkilde

Vi kan placere vores kode et par forskellige steder. Alle har nogle fordele og ulemper.

2.1. Byg script

Vi kan simpelthen placere kildekoden for vores plugin inde i selve build-scriptet. Dette giver os automatisk kompilering og inkludering af pluginet.

Det er meget simpelt, men vores plugin vil ikke være synlig uden for build-scriptet. På grund af det kan vi ikke genbruge det i andre build-scripts.

2.2. BuildSrc Folder

En anden mulighed, som vi kan bruge, er at placere kildekoden til vores plugin i buildSrc / src / main / java folder.

Når du kører Gradle, kontrollerer den for eksistensen af buildSrc folder. Hvis det findes, bygger Gradle automatisk og inkluderer vores plugin.

Dette giver os muligheden for at dele vores plugin mellem forskellige build-scripts, men vi kan stadig ikke bruge det til andre projekter.

2.3. Selvstændigt projekt

Endelig kan vi oprette vores plugin som et separat projekt, der gør pluginet fuldt genanvendeligt i forskellige projekter.

For at bruge det i et eksternt projekt skal vi dog samle det i en jar-fil og føje til et projekt.

3. Vores første plugin

Lad os starte med det grundlæggende - hvert Gradle Plugin skal implementere com.gradle.api.Plugin interface.

Interfacet er generisk, så vi kan parametrere det med forskellige parametertyper. Normalt er parametertypen org.gradle.api.Project.

Vi kan dog bruge forskellige typeparametre, så pluginet anvendes i forskellige levetidsfaser:

• ved brug af org.gradle.api.Settings vil resultere i at anvende pluginet til et indstillingsskript
• ved brug af org.gradle.api.Gradle vil resultere i at anvende pluginet til et initialiseringsscript

Det enkleste plugin, vi kan oprette, er et Hej Verden Ansøgning:

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

Vi kan nu anvende det ved at tilføje en linje inde i vores build-script:

anvend plugin: GreetingPlugin

Nu efter at have ringet grad hej, vi får at se “Hej Gradle” besked i logfiler.

4. Plugin-konfiguration

De fleste plugins har brug for adgang til en ekstern konfiguration fra build-scriptet.

Vi kan gøre det ved at bruge udvidelsesobjekter:

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

Lad os nu tilføje det nye udvidelsesobjekt til vores plugin-klasse:

@Override public void apply (Project project) {GreetingPluginExtension extension = project.getExtensions () .create ("greeting", GreetingPluginExtension.class); project.task ("hej") .doLast (opgave -> {System.out.println ("Hej" + udvidelse.getGreeter ()); System.out.println ("Jeg har en besked til dig:" + udvidelse .getMessage ());}); }

Nu når vi ringer grad hej, vi ser standardmeddelelsen defineret i vores HilsenPluginExtension.

Men da vi har oprettet udvidelsen, kan vi bruge en lukning til at gøre det inde i build-scriptet:

hilsen {greeter = "Stranger" message = "Besked fra build-scriptet"}

5. Standalone Plugin-projekt

For at oprette en enkeltstående Gradle-plugins er vi nødt til at gøre lidt mere arbejde.

5.1. Opsætning

For det første skal vi importere Gradle API-afhængighed - hvilket er ret ligetil:

afhængigheder {kompilér gradleApi ()}

Bemærk, at det er nødvendigt at gøre det samme i Maven gradle-tooling-api afhængighed - fra Gradle-arkivet:

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

5.2. Ledningsføring af pluginet

For at tillade Gradle at finde implementeringen af ​​vores enkeltstående plugin, skal vi oprette egenskabsfilen i src / main / ressourcer / META-INF /gradle-plugins.

Ressourcefilen skal have et navn, der matcher plugin-id'et. Så hvis vores plugin har et id på org.baeldung.greeting, den nøjagtige sti for filen ville være META-INF / gradle-plugins / org.baeldung.greeting.properties.

Dernæst kan vi definere implementeringsklassen for pluginet:

 implementeringsklasse = org.gradle.GreetingPlugin

Det implementeringsklasse skal svare til det fulde pakkenavn i vores plugin-klasse.

5.3. Oprettelse af plugin-id'et

Der er nogle regler og konventioner, som plugin-ID skal følge i Gradle. De fleste af dem ligner reglerne for pakkenavn i Java:

• De kan kun indeholde alfanumeriske tegn “.” og “-“
• Id'et skal have mindst et "." adskiller domænenavnet fra pluginnavnet
• Navneområder org.gradle og com.gradleware er begrænset
• Et id kan ikke starte eller slutte med “.”
• Ingen to eller flere på hinanden følgende “.” tegn er tilladt

Endelig er der en konvention om, at plugin-id skal være et mindre bogstav, der følger omvendt domænenavnkonvention.

Den største forskel mellem Java-pakkenavne og Gradle-pluginavne er, at pakkenavnet normalt er mere detaljeret end plugin-id'et.

5.4. Udgivelses-plugin

Når vi vil udgive vores plugin for at kunne genbruge det i eksterne projekter, har vi to måder at opnå det på.

For det første, vi kan udgive vores plugin JAR til et eksternt lager som Maven eller Vedbend.

Alternativt kan vi bruge Gradle Plugin Portal. Dette gør det muligt for vores plugin at være tilgængeligt af et bredt Gradle Community. Mere om udgivelse af projekter til Gradle-arkivet kan findes i Gradle Plugin Portal Documentation.

5.5. Java Gradle Development Plugin

Når vi skriver vores plugins i Java, kan vi drage fordel af Java Gradle Development Plugin.

Dette kompileres automatisk og tilføjes gradleApi () afhængigheder. Det udfører også validering af plugin-metadata som en del af gradle krukke opgave.

Vi kan tilføje plugin ved at tilføje følgende blok til vores build-script:

plugins {id 'java-gradle-plugin'}

6. Test af plugins

For at teste, at vores plugin fungerer korrekt, og det anvendes korrekt på Projekt, vi kan bruge org.gradle.testfixtures.ProjectBuilder for at oprette en forekomst af Projekt.

Vi kan derefter kontrollere, om pluginet blev anvendt, og at korrekte opgaver er til stede i vores Projekt eksempel. Vi kan bruge standard JUnit test for at gøre det:

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

7. Resume

I denne artikel har vi vist det grundlæggende ved at skrive tilpassede plugins i Gradle. For at gå mere i dybden med oprettelse af plugins skal du kigge på Gradle-dokumentationen.

Og som altid kan alle kodeeksempler findes på Github.

Næste » Oprettelse af en fed krukke i Gradle « Forrige Ant vs Maven vs Gradle