Ant vs Maven vs Gradle

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

• Ant vs Maven vs Gradle (nåværende artikkel) • Skriver tilpassede Gradle-plugins

• Lage en fettkrukke i Gradle

1. Introduksjon

I denne artikkelen vil vi utforske tre Java-bygningsautomatiseringsverktøy som dominerte JVM-økosystemet - Ant, Maven og Gradle.

Vi presenterer hver av dem og utforsker hvordan Java-bygningsautomatiseringsverktøy utviklet seg.

2. Apache Ant

I begynnelsen var Make det eneste verktøyet for byggeautomatisering tilgjengelig utover hjemmelagde løsninger. Make har eksistert siden 1976, og som sådan ble det brukt til å bygge Java-applikasjoner i de tidlige Java-årene.

Imidlertid passet mange konvensjoner fra C-programmer ikke i Java-økosystemet, så med tiden overtok Ant som et bedre alternativ.

Apache Ant (“Another Neat Tool”) er et Java-bibliotek som brukes til å automatisere byggeprosesser for Java-applikasjoner. I tillegg kan Ant brukes til å bygge applikasjoner som ikke er Java. Det var opprinnelig en del av Apache Tomcat-kodebasen og ble utgitt som et frittstående prosjekt i 2000.

I mange aspekter er Ant veldig lik Make, og det er enkelt nok slik at alle kan begynne å bruke det uten spesielle forutsetninger. Ant build-filer skrives i XML, og etter konvensjon kalles de build.xml.

Ulike faser i en byggeprosess kalles “mål”.

Her er et eksempel på en build.xml fil for et enkelt Java-prosjekt med Hei Verden hovedklasse:

Denne build-filen definerer fire mål: ren, kompilere, krukke og løpe. For eksempel kan vi kompilere koden ved å kjøre:

maur kompilere

Dette vil utløse målet ren først som vil slette "klasser" -katalogen. Etter det, målet kompilere vil gjenskape katalogen og kompilere src-mappen i den.

Den viktigste fordelen med Ant er dens fleksibilitet. Maur pålegger ikke kodingskonvensjoner eller prosjektstrukturer. Følgelig betyr dette at Ant krever at utviklere skriver alle kommandoene alene, noe som noen ganger fører til store XML-byggefiler som er vanskelig å vedlikeholde.

Siden det ikke er noen konvensjoner, betyr det bare å kjenne Ant ikke at vi raskt vil forstå noen Ant-byggfiler. Det vil sannsynligvis ta litt tid å bli vant til en ukjent Ant-fil, noe som er en ulempe i forhold til de andre, nyere verktøyene.

Til å begynne med hadde Ant ingen innebygd støtte for avhengighetsstyring. Da avhengighetsadministrasjon ble et must de senere årene, ble Apache Ivy imidlertid utviklet som et delprosjekt av Apache Ant-prosjektet. Den er integrert med Apache Ant, og følger de samme designprinsippene.

Imidlertid førte de første Ant-begrensningene på grunn av ikke å ha innebygd støtte for avhengighetsadministrasjon og frustrasjoner når du arbeider med uhåndterbare XML-byggefiler til opprettelsen av Maven.

3. Apache Maven

Apache Maven er et avhengighetsstyring og et byggeautomatiseringsverktøy, primært brukt for Java-applikasjoner. Maven fortsetter å bruke XML-filer akkurat som Ant, men på en mye mer håndterbar måte. Navnet på spillet her er konvensjon over konfigurasjon.

Mens Maur gir fleksibilitet og krever at alt skrives fra bunnen av, Maven er avhengig av konvensjoner og gir forhåndsdefinerte kommandoer (mål).

Enkelt sagt, Maven lar oss fokusere på hva bygningen vår skal gjøre, og gir oss rammene for å gjøre det. Et annet positivt aspekt ved Maven var at den ga innebygd støtte for avhengighetsstyring.

Mavens konfigurasjonsfil, som inneholder instruksjoner om bygging og avhengighetsadministrasjon, kalles etter konvensjon pom.xml. I tillegg foreskriver Maven også en streng prosjektstruktur, mens Ant også gir fleksibilitet der.

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

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

Nå er imidlertid prosjektstrukturen også standardisert og i samsvar med Maven-konvensjonene:

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

I motsetning til Ant er det ikke behov for å definere hver av fasene i byggeprosessen manuelt. I stedet kan vi bare ringe Mavens innebygde kommandoer.

For eksempel kan vi kompilere koden ved å kjøre:

mvn kompilere

Som kjent på offisielle sider, Maven kan betraktes som et rammeverk for utførelse av plugins, siden alt arbeidet gjøres av plugins. Maven støtter et bredt utvalg av tilgjengelige plugins, og hver av dem kan konfigureres i tillegg.

En av de tilgjengelige pluginene er Apache Maven Dependency Plugin som har en kopi-avhengigheter mål som vil kopiere våre avhengigheter til en spesifisert katalog.

For å vise dette pluginet i aksjon, la oss ta med dette pluginet i vårt pom.xml fil og konfigurer en utdatakatalog for våre avhengigheter:

   org.apache.maven.plugins maven-avhengighet-plugin kopi-avhengigheter pakke kopi-avhengighetsmål / avhengigheter 

Dette programtillegget kjøres i en pakke fase, så hvis vi løper:

mvn-pakke

Vi utfører dette pluginet og kopierer avhengigheter til mål- / avhengighetsmappen.

Det er også en eksisterende artikkel om hvordan du lager en kjørbar JAR ved hjelp av forskjellige Maven-plugins. I tillegg, for en detaljert Maven-oversikt, ta en titt på denne kjerneguiden på Maven, hvor noen av Mavens viktigste funksjoner blir utforsket.

Maven ble veldig populær siden build-filer nå ble standardisert, og det tok betydelig kortere tid å vedlikeholde build-filer, sammenlignet med Ant. Imidlertid, selv om de er mer standardiserte enn Ant-filer, har Maven-konfigurasjonsfiler fortsatt en tendens til å bli store og tungvint.

Mavens strenge konvensjoner kommer med prisen for å være mye mindre fleksibel enn Ant. Måltilpasning er veldig vanskelig, så det er mye vanskeligere å skrive tilpassede byggeskripter, sammenlignet med Ant.

Selv om Maven har gjort noen alvorlige forbedringer når det gjelder å gjøre applikasjonens byggeprosesser enklere og mer standardiserte, kommer det fortsatt til en pris på grunn av å være mye mindre fleksibel enn Ant. Dette førte til etableringen av Gradle som kombinerer det beste fra begge verdener - Ants fleksibilitet og Mavens funksjoner.

4. Gradle

Gradle er en avhengighetsstyring og et bygningsautomatiseringsverktøy som ble bygget på konseptene Ant og Maven.

En av de første tingene vi kan merke oss om Gradle er at den ikke bruker XML-filer, i motsetning til Ant eller Maven.

Over tid ble utviklerne mer og mer interessert i å ha og jobbe med et domenespesifikt språk - som enkelt sagt ville tillate dem å løse problemer i et bestemt domene ved hjelp av et språk skreddersydd for det aktuelle domenet.

Dette ble vedtatt av Gradle, som bruker en DSL basert på Groovy eller Kotlin. Dette førte til mindre konfigurasjonsfiler med mindre rot siden språket var spesielt designet for å løse spesifikke domeneproblemer. Gradles konfigurasjonsfil kalles etter konvensjon build.gradle i Groovy, eller build.gradle.kts i Kotlin.

Legg merke til at Kotlin tilbyr bedre IDE-støtte enn Groovy for automatisk fullføring og feildeteksjon.

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

bruk plugin: 'java' repositories {mavenCentral ()} jar {baseName = 'gradleExample' version = '0.0.1-SNAPSHOT'} avhengigheter {testImplementation 'junit: junit: 4.12'}

Vi kan kompilere koden ved å kjøre:

graderingskurs

I sin kjerne gir Gradle med vilje veldig lite funksjonalitet. Plugins legger til alle nyttige funksjoner. I vårt eksempel brukte vi java plugin som lar oss kompilere Java-kode og andre verdifulle funksjoner.

Gradle ga byggetrinnene navnet “oppgaver”, i motsetning til Ant “mål” eller Mavens “faser”. Med Maven brukte vi Apache Maven Dependency Plugin, og det er et spesifikt mål å kopiere avhengigheter til en spesifisert katalog. Med Gradle kan vi gjøre det samme ved å bruke oppgaver:

oppgavekopiavhengighet (type: Kopi) {fra konfigurasjoner.kompiler til 'avhengigheter'}

Vi kan kjøre denne oppgaven ved å utføre:

gradere kopi Avhengigheter

5. Konklusjon

I denne artikkelen presenterte vi Ant, Maven og Gradle - tre Java-automatiseringsverktøy.

Ikke overraskende har Maven majoriteten av markedet for byggeverktøy i dag.

Gradle har imidlertid sett god adopsjon i mer komplekse kodebaser, av følgende grunner:

  • Mange open source-prosjekter som Spring bruker det nå
  • Det er raskere enn Maven for de fleste scenarier, takket være den trinnvise bygningen
  • Det tilbyr avanserte analyse- og feilsøkingstjenester

Imidlertid ser det ut til at Gradle har en brattere læringskurve, spesielt hvis du ikke er kjent med Groovy eller Kotlin.

Neste » Skriver tilpassede Gradle-plugins « Forrige introduksjon til Gradle

$config[zx-auto] not found$config[zx-overlay] not found