streamalism.org

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

• Ant vs Maven vs Gradle (nuværende artikel) • Skrivning af brugerdefinerede Gradle-plugins

• Oprettelse af en fed krukke i Gradle

1. Introduktion

I denne artikel undersøger vi tre Java bygger automatiseringsværktøjer, der dominerede JVM-økosystemet - Ant, Maven og Gradle.

Vi introducerer hver af dem og udforsker, hvordan Java-byggeautomatiseringsværktøjer udviklede sig.

2. Apache Ant

I begyndelsen var Make det eneste build-automatiseringsværktøj tilgængelig udover hjemmelavede løsninger. Make har eksisteret siden 1976, og som sådan blev det brugt til at opbygge Java-applikationer i de tidlige Java-år.

Imidlertid passede mange konventioner fra C-programmer ikke ind i Java-økosystemet, så med tiden overtog Ant som et bedre alternativ.

Apache Ant (“Another Neat Tool”) er et Java-bibliotek, der bruges til automatisering af byggeprocesser til Java-applikationer. Derudover kan Ant bruges til at opbygge ikke-Java-applikationer. Det var oprindeligt en del af Apache Tomcat codebase og blev frigivet som et selvstændigt projekt i 2000.

I mange aspekter ligner Ant meget Make, og det er simpelt nok, så alle kan begynde at bruge det uden særlige forudsætninger. Ant build-filer skrives i XML, og efter konvention kaldes de build.xml.

Forskellige faser i en byggeproces kaldes "mål".

Her er et eksempel på en build.xml fil til et simpelt Java-projekt med Hej Verden hovedklasse:

Denne buildfil definerer fire mål: ren, udarbejde, krukke og løb. For eksempel kan vi kompilere koden ved at køre:

ant kompilering

Dette udløser målet ren først, som sletter "klasser" -mappen. Derefter målet udarbejde vil genskabe biblioteket og kompilere src-mappen i det.

Den største fordel ved Ant er dens fleksibilitet. Maur pålægger ikke kodningskonventioner eller projektstrukturer. Derfor betyder dette, at Ant kræver, at udviklere skriver alle kommandoerne alene, hvilket undertiden fører til store XML-buildfiler, der er svære at vedligeholde.

Da der ikke er nogen konventioner, betyder det bare at kende Ant ikke, at vi hurtigt forstår enhver Ant-build-fil. Det vil sandsynligvis tage noget tid at vænne sig til en ukendt Ant-fil, hvilket er en ulempe i forhold til de andre nyere værktøjer.

Først havde Ant ingen indbygget støtte til afhængighedsstyring. Da afhængighedsstyring blev et must i de senere år, blev Apache Ivy imidlertid udviklet som et underprojekt til Apache Ant-projektet. Det er integreret med Apache Ant, og det følger de samme designprincipper.

De oprindelige Ant-begrænsninger på grund af manglende indbygget understøttelse af afhængighedsstyring og frustrationer, når man arbejder med ikke-håndterbare XML-buildfiler førte imidlertid til oprettelsen af ​​Maven.

3. Apache Maven

Apache Maven er en afhængighedsstyring og et byggeautomatiseringsværktøj, der primært bruges til Java-applikationer. Maven fortsætter med at bruge XML-filer ligesom Ant, men på en meget mere håndterbar måde. Navnet på spillet her er konvention over konfiguration.

Mens Ant giver fleksibilitet og kræver, at alt skrives fra bunden, Maven er afhængig af konventioner og leverer foruddefinerede kommandoer (mål).

Kort sagt giver Maven os mulighed for at fokusere på, hvad vores build skal gøre, og giver os rammerne for at gøre det. Et andet positivt aspekt ved Maven var, at det leverede indbygget support til afhængighedsstyring.

Mavens konfigurationsfil, der indeholder bygnings- og afhængighedsstyringsinstruktioner, kaldes ved konvention pom.xml. Derudover ordinerer Maven også en streng projektstruktur, mens Ant også giver fleksibilitet der.

Her er et eksempel på en pom.xml fil til det samme enkle Java-projekt med Hej Verden hovedklasse fra før:

 4.0.0 baeldung maven Eksempel 0.0.1-SNAPSHOT Maven eksempel junit junit 4.12 test 

Men nu er projektstrukturen også standardiseret og i overensstemmelse med Maven-konventionerne:

+ --- src | + --- hoved | | + --- java | | | \ --- com | | | \ --- baeldung | | | \ --- maven | | | HelloWorld.java | | | | | \ --- ressourcer | \ --- test | + --- java | \ --- ressourcer

I modsætning til Ant er der ikke behov for at definere hver af faserne i byggeprocessen manuelt. I stedet kan vi blot kalde Mavens indbyggede kommandoer.

For eksempel kan vi kompilere koden ved at køre:

mvn kompilere

Som det er bemærket på officielle sider, Maven kan betragtes som en implementeringsramme for plugin, da alt arbejde udføres af plugins. Maven understøtter en bred vifte af tilgængelige plugins, og hver af dem kan yderligere konfigureres.

Et af de tilgængelige plugins er Apache Maven Dependency Plugin, som har en kopi-afhængigheder mål, der vil kopiere vores afhængigheder til en bestemt mappe.

For at vise dette plugin i aktion, lad os medtage dette plugin i vores pom.xml fil og konfigurer en outputkatalog til vores afhængigheder:

   org.apache.maven.plugins maven-afhængighed-plugin kopi-afhængigheder pakke kopi-afhængighedsmål / afhængigheder 

Dette plugin udføres i en pakke fase, så hvis vi løber:

mvn-pakke

Vi udfører dette plugin og kopierer afhængigheder til målet / afhængighedsmappen.

Der er også en eksisterende artikel om, hvordan man opretter en eksekverbar JAR ved hjælp af forskellige Maven-plugins. Derudover, for en detaljeret Maven-oversigt, skal du se på denne kernevejledning om Maven, hvor nogle Mavens nøglefunktioner udforskes.

Maven blev meget populær, da build-filer nu var standardiserede, og det tog betydeligt kortere tid at vedligeholde build-filer sammenlignet med Ant. Men selvom de er mere standardiserede end Ant-filer, har Maven-konfigurationsfiler stadig en tendens til at blive store og besværlige.

Mavens strenge konventioner kommer med prisen for at være meget mindre fleksibel end Ant. Måltilpasning er meget hård, så det er meget sværere at lave tilpassede build-scripts sammenlignet med Ant.

Selvom Maven har foretaget nogle alvorlige forbedringer med hensyn til at gøre applikations byggeprocesser lettere og mere standardiserede, kommer det stadig med en pris på grund af at være meget mindre fleksibel end Ant. Dette førte til oprettelsen af ​​Gradle, der kombinerer det bedste fra begge verdener - Ant's fleksibilitet og Mavens funktioner.

4. Gradle

Gradle er en afhængighedsstyring og et bygningsautomatiseringsværktøj, der blev bygget på begreberne Ant og Maven.

En af de første ting, vi kan bemærke om Gradle, er, at den ikke bruger XML-filer, i modsætning til Ant eller Maven.

Over tid blev udviklere mere og mere interesseret i at have og arbejde med et domænespecifikt sprog - hvilket ganske enkelt sagt ville give dem mulighed for at løse problemer i et specifikt domæne ved hjælp af et sprog, der er skræddersyet til det pågældende domæne.

Dette blev vedtaget af Gradle, som bruger en DSL baseret enten på Groovy eller Kotlin. Dette førte til mindre konfigurationsfiler med mindre rod, da sproget var specielt designet til at løse specifikke domæne problemer. Gradles konfigurationsfil kaldes ved konvention build.gradle i Groovy, eller build.gradle.kts i Kotlin.

Bemærk, at Kotlin tilbyder bedre IDE-support end Groovy til automatisk udfyldelse og fejlregistrering.

Her er et eksempel på en build.gradle fil til det samme enkle Java-projekt med Hej Verden hovedklasse fra før:

anvend plugin: 'java' repositories {mavenCentral ()} jar {baseName = 'gradleExample' version = '0.0.1-SNAPSHOT'} afhængigheder {testImplementation 'junit: junit: 4.12'}

Vi kan kompilere koden ved at køre:

gradlekurser

I sin kerne giver Gradle bevidst meget lidt funktionalitet. Plugins tilføjer alle nyttige funktioner. I vores eksempel brugte vi java plugin, der giver os mulighed for at kompilere Java-kode og andre værdifulde funktioner.

Gradle gav sine byggetrin navnet "opgaver" i modsætning til Ant's "mål" eller Mavens "faser". Med Maven brugte vi Apache Maven Dependency Plugin, og det er et specifikt mål at kopiere afhængigheder til en bestemt mappe. Med Gradle kan vi gøre det samme ved at bruge opgaver:

opgave copyDependencies (type: Copy) {fra konfigurations.compile til 'afhængigheder'}

Vi kan køre denne opgave ved at udføre:

gradle copyAfhængigheder

5. Konklusion

I denne artikel præsenterede vi Ant, Maven og Gradle - tre Java-automatiseringsværktøjer.

Ikke overraskende besidder Maven størstedelen af ​​markedet for byggeværktøjer i dag.

Gradle har imidlertid set god vedtagelse i mere komplekse kodebaser af følgende grunde:

• Masser af open source-projekter som Spring bruger det nu
• Det er hurtigere end Maven i de fleste scenarier takket være dets inkrementelle builds
• Det tilbyder avancerede analyse- og fejlretningstjenester

Imidlertid synes Gradle at have en stejlere indlæringskurve, især hvis du ikke er fortrolig med Groovy eller Kotlin.

Næste » Skrivning af brugerdefinerede Gradle-plugins « Tidligere introduktion til Gradle