streamalism.org

Dit artikel maakt deel uit van een reeks: • Inleiding tot Gradle

• Ant vs Maven vs Gradle

• Aangepaste Gradle-plug-ins schrijven (huidig ​​artikel) • Een Fat Jar maken in Gradle

1. Inleiding

Gradle is een zeer populaire bouwtool, die vaak wordt gewaardeerd vanwege het zeer aanpasbare bouwproces.

Vandaag gaan we laten zien hoe we aangepaste Gradle-plug-ins kunnen maken, waarmee we het bouwproces kunnen aanpassen buiten wat we kunnen bereiken met de standaardconfiguratie.

2. Locatie van plug-inbron

We kunnen onze code op een paar verschillende locaties plaatsen. Ze hebben allemaal een aantal voor- en nadelen.

2.1. Build Script

We kunnen eenvoudig de broncode van onze plug-in in het build-script zelf plaatsen. Dit geeft ons een automatische compilatie en opname van de plug-in.

Het is heel eenvoudig, maar onze plug-in is niet zichtbaar buiten het build-script. Daarom kunnen we het niet hergebruiken in andere build-scripts.

2.2. BuildSrc Map

Een andere mogelijkheid die we kunnen gebruiken, is het plaatsen van de broncode van onze plug-in in het buildSrc / src / main / java map.

Wanneer u Gradle uitvoert, wordt gecontroleerd op het bestaan ​​van het buildSrc map. Als dat bestaat, zal Gradle automatisch onze plug-in bouwen en opnemen.

Dit geeft ons de mogelijkheid om onze plug-in te delen tussen verschillende build-scripts, maar we kunnen deze nog steeds niet gebruiken in andere projecten.

2.3. Op zichzelf staand project

Ten slotte kunnen we onze plug-in als een apart project maken, waardoor de plug-in volledig herbruikbaar is in verschillende projecten.

Om het echter in een extern project te gebruiken, moeten we het in een jar-bestand bundelen en aan een project toevoegen.

3. Onze eerste plug-in

Laten we beginnen met de basis - elke Gradle-plug-in moet het com.gradle.api.Plugin koppel.

De interface is generiek, dus we kunnen deze parametriseren met verschillende parametertypen. Gewoonlijk is het parametertype org.gradle.api.Project.

We kunnen echter verschillende typeparameters gebruiken, zodat de plug-in in verschillende levensfasen wordt toegepast:

• gebruik makend van org.gradle.api.Settings zal resulteren in het toepassen van de plug-in op een instellingenscript
• gebruik makend van org.gradle.api.Gradle zal resulteren in het toepassen van de plug-in op een initialisatiescript

De eenvoudigste plug-in die we kunnen maken is een Hallo Wereld toepassing:

public class GreetingPlugin implementeert Plugin {@Override public void apply (Project project) {project.task ("hallo") .doLast (task -> System.out.println ("Hallo Gradle!")); }}

We kunnen het nu toepassen door een regel toe te voegen aan ons build-script:

plug-in toepassen: GreetingPlugin

Nu, na het bellen hallo hallo, we zullen zien "Hallo Gradle" bericht in logboeken.

4. Plug-in configuratie

De meeste plug-ins hebben toegang nodig tot een externe configuratie vanuit het build-script.

Dat kunnen we doen door gebruik te maken van extensie objecten:

openbare klasse GreetingPluginExtension {private String greeter = "Baeldung"; private String message = "Bericht van de plug-in!" // standaard getters en setters}

Laten we nu het nieuwe toevoegen extensie object naar onze plugin-klasse:

@Override public void apply (Project-project) {GreetingPluginExtension extension = project.getExtensions () .create ("greeting", GreetingPluginExtension.class); project.task ("hallo") .doLast (taak -> {System.out.println ("Hallo," + extension.getGreeter ()); System.out.println ("Ik heb een bericht voor jou:" + extensie .getMessage ());}); }

Nu, als we bellen hallo hallo, we zullen het standaardbericht zien dat is gedefinieerd in ons GroetPluginExtension.

Maar aangezien we de extensie hebben gemaakt, kunnen we een sluiting gebruiken om dat te doen in het build-script:

groet {greeter = "Stranger" message = "Bericht van het build-script"}

5. Standalone plugin-project

Om zelfstandige Gradle-plug-ins te maken, moeten we wat meer werk doen.

5.1. Opstelling

Ten eerste moeten we de Gradle API-afhankelijkheid importeren - wat vrij eenvoudig is:

afhankelijkheden {compileer gradleApi ()}

Merk op dat hetzelfde in Maven vereist is gradle-tooling-api afhankelijkheid - uit de Gradle-repository:

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

5.2. Bedrading van de plug-in

Om Gradle in staat te stellen de implementatie van onze zelfstandige plug-in te vinden, moeten we het eigenschappenbestand maken in het src / main / resources / META-INF /gradle-plug-ins.

Het bronbestand moet een naam hebben die overeenkomt met de plug-in-id. Dus als onze plug-in een id heeft van org.baeldung.greeting, het exacte pad van het bestand zou zijn META-INF / gradle-plugins / org.baeldung.greeting.properties.

Vervolgens kunnen we de implementatieklasse van de plug-in definiëren:

 implementatie-class = org.gradle.GreetingPlugin

De implementatie-klasse moet gelijk zijn aan de volledige pakketnaam van onze plugin-klasse.

5.3. De plug-in-ID maken

Er zijn enkele regels en conventies die plug-in-ID moet volgen in Gradle. De meeste zijn vergelijkbaar met pakketnaamregels in Java:

• Ze mogen alleen alfanumerieke tekens bevatten, "." en "-"
• De id moet ten minste één '' hebben. '' door de domeinnaam te scheiden van de naam van de plug-in
• Naamruimten org.gradle en com.gradleware zijn beperkt
• Een ID kan niet beginnen of eindigen met '.'
• Geen twee of meer opeenvolgende "." tekens zijn toegestaan

Ten slotte is er een conventie dat plug-in-id een naam in kleine letters moet zijn die de omgekeerde domeinnaamconventie volgt.

Het belangrijkste verschil tussen Java-pakketnamen en Gradle-plug-in-namen is dat de pakketnaam meestal gedetailleerder is dan de plug-in-ID.

5.4. Plug-in voor publiceren

Als we onze plug-in willen publiceren om deze opnieuw te kunnen gebruiken in externe projecten, hebben we twee manieren om dat te bereiken.

Ten eerste, we kunnen onze plug-in JAR publiceren naar een externe repository zoals Maven of Klimop.

Als alternatief kunnen we de Gradle Plugin Portal gebruiken. Hierdoor is onze plug-in toegankelijk voor een brede Gradle-community. Meer over het publiceren van projecten naar de Gradle-repository is te vinden in Gradle Plugin Portal Documentation.

5.5. Java Gradle Development-plug-in

Wanneer we onze plug-ins in Java schrijven, kunnen we profiteren van de Java Gradle Development-plug-in.

Dit zal automatisch compileren en toevoegen gradleApi () afhankelijkheden. Het zal ook de metadata-validatie van plug-ins uitvoeren als onderdeel van het gradle pot taak.

We kunnen een plug-in toevoegen door het volgende blok aan ons build-script toe te voegen:

plug-ins {id 'java-gradle-plugin'}

6. Plug-ins testen

Om te testen of onze plug-in correct werkt en correct wordt toegepast op het Project, we kunnen gebruiken org.gradle.testfixtures.ProjectBuilder om een ​​instantie van het Project.

We kunnen dan controleren of de plug-in is toegepast en of de juiste taken aanwezig zijn in ons Project voorbeeld. We kunnen standaard gebruiken JUnit tests om dat te doen:

@Test openbare ongeldige groetTest () {Projectproject = ProjectBuilder.builder (). Build (); project.getPluginManager (). apply ("com.baeldung.greeting"); assertTrue (project.getPluginManager () .hasPlugin ("com.baeldung.greeting")); assertNotNull (project.getTasks (). getByName ("hallo")); }

7. Samenvatting

In dit artikel hebben we de basisprincipes van het schrijven van aangepaste plug-ins in Gradle laten zien. Bekijk de Gradle-documentatie om dieper in te gaan op het maken van plug-ins.

En, zoals altijd, zijn alle codevoorbeelden te vinden op Github.

De volgende » Een vetpot maken in Gradle « Voorgaand Ant vs Maven vs Gradle