streamalism.org

1. Oversigt

Gradle bruges almindeligvis af udviklere til at styre deres projekts livscyklus. Det er standardvalg af byggeværktøj til alle nye Android-projekter.

I denne vejledning lærer vi om Gradle Wrapper, et ledsagende værktøj, der gør det lettere at distribuere projekter.

2. Gradle indpakning

For at opbygge et Gradle-baseret projekt er vi nødt til at have Gradle installeret i vores maskine. Men hvis vores installerede version ikke stemmer overens med projektets version, står vi sandsynligvis over for mange inkompatibilitetsproblemer.

Gradle Wrapper, også kaldet Indpakning kort sagt løser dette problem. Det er et script, der kører Gradle-opgaver med en deklareret version. Hvis den deklarerede version ikke er installeret, installerer Wrapper den nødvendige.

De vigtigste fordele ved indpakning er, at vi kan:

• Byg et projekt med Wrapper på enhver maskine uden behov for at installere Gradle først
• Har en fast Gradle-version. Dette giver genanvendelige og mere robuste bygger på CI-rørledninger
• Opgrader til en ny Gradle-version let ved at ændre Wrapper-definitionen

I de næste sektioner kører vi Gradle-opgaver, der kræver, at Gradle installeres lokalt.

2.1. Generering af indpakningsfiler

For at bruge Wrapper er vi nødt til at generere nogle bestemte filer. Vi genererer disse filer ved hjælp af den indbyggede Gradle-opgave, der hedder indpakning. Bemærk, at vi kun skal generere disse filer en gang.

Lad os nu køre indpakning opgave i vores projektmappe:

$ gradle indpakning 

Lad os se output fra denne kommando:

Lad os se på, hvad disse filer er:

• gradle-wrapper.jar indeholder kode til download af Gradle-distributionen, der er angivet i gradle-wrapper.egenskaber fil
• gradle-wrapper.egenskaber indeholder Wrapper runtime egenskaber - vigtigst af alt den version af Gradle-distributionen, der er kompatibel med det aktuelle projekt
• gradlew er scriptet, der udfører Gradle-opgaver med Wrapper
• gradlew.bat er gradlew tilsvarende batch script til Windows-maskiner

Som standard er indpakning opgave genererer Wrapper-filer med Gradle-versionen, der aktuelt er installeret på maskinen. Vi kan angive en anden version, hvis det er nødvendigt:

$ gradle wrapper - gradle-version 6.3 

Vi anbefalede at kontrollere Wrapper-filerne ikildekontrolsystemet ligesom GitHub. På denne måde sikrer vi, at andre udviklere kan køre projektet uden behov for at installere Gradle.

2.2. Kører Gradle-kommandoer med Wrapper

Vi kan køre enhver Gradle-opgave med Wrapper ved at erstatte den gradle med gradlew.

For at liste de tilgængelige opgaver kan vi bruge gradlew opgaver kommando:

$ gradlew opgaver

Lad os se på output:

Hjælpopgaver ---------- buildEnvironment - Viser alle buildscript-afhængigheder, der er erklæret i rodprojektets 'gradle-wrapper'. komponenter - Viser komponenter produceret af rodprojektet 'gradle-wrapper'. [inkubering] afhængigheder - Viser alle afhængigheder, der er erklæret i rodprojektets 'gradle-wrapper'. dependencyInsight - Viser indsigt i en bestemt afhængighed i rodprojektets 'gradle-wrapper'. dependComponents - Viser de afhængige komponenter af komponenter i rodprojekt 'gradle-wrapper'. [inkubering] hjælp - Viser en hjælpemeddelelse. model - Viser konfigurationsmodellen for rodprojektet 'gradle-wrapper'. [inkubering] udgående Varianter - Viser de udgående varianter af rodprojektet 'gradle-wrapper'. projekter - Viser underprojekterne til rodprojektet 'gradle-wrapper'. egenskaber - Viser egenskaberne for rodprojektet 'gradle-wrapper'. opgaver - Viser de opgaver, der kan køres fra rodprojektets 'gradle-wrapper'.

Som vi kan se, er output det samme, som vi ville få, når vi kører denne opgave med gradle kommando.

3. Almindelige problemer

Lad os nu se på nogle almindelige problemer, som vi måske står over for, når vi arbejder med Wrapper.

3.1. Global .gitignore, der ignorerer alle Jar-filer

Nogle organisationer tillader ikke udviklere at kontrollere jar-filer i deres kildekontrolsystem. Sådanne projekter har typisk en regel i det globale .gitignore fil for at ignorere alle jar-filer. Derfor er den gradle-wrapper.jar filen kontrolleres ikke i git-arkivet. Af denne grund kører Wrapper-opgaver ikke på andre maskiner. I sådanne tilfælde, vi skal tilføje gradle-wrapper.jar fil til git med kraft:

git add -f gradle / wrapper / gradle-wrapper.jar

På samme måde kan vi have et projektspecifikt .gitignore fil, der ignorerer jar-filer. Vi kan ordne det enten ved at slappe af .gitignore regel eller ved at tilføje wrapper jar-filen kraftigt som vist ovenfor.

3.2. Manglende indpakningsmappe

Når vi tjekker et Wrapper-baseret projekt, kan vi glemme at inkludere indpakning mappe, der findes inde i gradle folder. Men som vi har set ovenfor, indpakning mappen indeholder to vigtige filer: gradle-wrapper.jar og gradle-wrapper.egenskaber.

Uden disse filer får vi fejl, når vi kører Gradle-opgaver med Wrapper. Derfor, vi skal kontrollere indpakning mappe ind i kildekontrolsystemet.

3.3. Fjernede indpakningsfiler

Gradle-baserede projekter indeholder en .gradle mappe, der gemmer cache for at fremskynde Gradle-opgaver. Nogle gange er vi nødt til at rydde cachen for at fejlfinde problemer med Gradle-opbygning. Normalt fjerner vi hele .gradle folder. Men vi kan tage fejl af indpakningen gradle mappe med .gradle mappen og fjern den også. Derefter står vi helt sikkert over for problemer, når vi prøver at køre Gradle-opgaver med Wrapper.

Vi kan løse dette problem ved at hente de seneste ændringer fra kilden. Alternativt kan vi regenerere Wrapper-filerne.

4. Konklusion

I denne vejledning lærte vi om Gradle Wrapper og dens grundlæggende brug. Vi lærte også om nogle almindelige problemer, vi kan have, når vi arbejder med Gradle Wrapper.

Som sædvanligt kan vi kontrollere projektet med genererede Gradle Wrapper-filer over på GitHub.