streamalism.org

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

• Ant vs Maven vs Gradle (huidig ​​artikel) • Aangepaste Gradle-plug-ins schrijven

• Een vetpot maken in Gradle

1. Inleiding

In dit artikel zullen we onderzoeken drie Java-ontwikkelaars voor automatiseringstools die het JVM-ecosysteem domineerden: Ant, Maven en Gradle.

We zullen ze allemaal introduceren en onderzoeken hoe Java-automatiseringstools zijn geëvolueerd.

2. Apache Ant

In het begin was Make de enige build-automatiseringstool beschikbaar buiten oplossingen van eigen bodem. Make bestaat al sinds 1976 en werd als zodanig in de vroege Java-jaren gebruikt voor het bouwen van Java-applicaties.

Veel conventies van C-programma's pasten echter niet in het Java-ecosysteem, dus na verloop van tijd nam Ant het over als een beter alternatief.

Apache Ant ("Another Neat Tool") is een Java-bibliotheek die wordt gebruikt voor het automatiseren van bouwprocessen voor Java-toepassingen. Bovendien kan Ant worden gebruikt voor het bouwen van niet-Java-applicaties. Het maakte aanvankelijk deel uit van de Apache Tomcat-codebase en werd in 2000 als een zelfstandig project uitgebracht.

Ant lijkt in veel opzichten erg op Make, en het is eenvoudig genoeg zodat iedereen het kan gebruiken zonder specifieke vereisten. Ant-buildbestanden zijn geschreven in XML en worden volgens afspraak genoemd build.xml.

Verschillende fasen van een bouwproces worden "doelen" genoemd.

Hier is een voorbeeld van een build.xml bestand voor een eenvoudig Java-project met de Hallo Wereld hoofdklasse:

Dit buildbestand definieert vier doelen: schoon, compileren, pot en rennen. We kunnen de code bijvoorbeeld compileren door het volgende uit te voeren:

ant compileren

Dit zal het doelwit activeren schoon eerst die de map "klassen" zal verwijderen. Daarna het doelwit compileren zal de directory opnieuw aanmaken en de src-map erin compileren.

Het belangrijkste voordeel van Ant is de flexibiliteit. Ant legt geen coderingsconventies of projectstructuren op. Bijgevolg betekent dit dat Ant van ontwikkelaars vereist dat ze alle opdrachten zelf schrijven, wat soms leidt tot enorme XML-buildbestanden die moeilijk te onderhouden zijn.

Aangezien er geen conventies zijn, betekent het kennen van Ant niet dat we snel elk Ant-buildbestand zullen begrijpen. Het zal waarschijnlijk enige tijd duren om te wennen aan een onbekend Ant-bestand, wat een nadeel is in vergelijking met de andere, nieuwere tools.

Aanvankelijk had Ant geen ingebouwde ondersteuning voor afhankelijkheidsbeheer. Omdat afhankelijkheidsbeheer in de latere jaren echter een must werd, werd Apache Ivy ontwikkeld als een subproject van het Apache Ant-project. Het is geïntegreerd met Apache Ant en volgt dezelfde ontwerpprincipes.

De aanvankelijke beperkingen van Ant als gevolg van het ontbreken van ingebouwde ondersteuning voor afhankelijkheidsbeheer en frustraties bij het werken met onbeheersbare XML-buildbestanden leidden tot de creatie van Maven.

3. Apache Maven

Apache Maven is een afhankelijkheidsbeheer en een buildautomatiseringstool, voornamelijk gebruikt voor Java-toepassingen. Maven blijft XML-bestanden gebruiken, net als Ant, maar op een veel beter beheersbare manier. De naam van het spel hier is conventie boven configuratie.

Hoewel Ant flexibiliteit biedt en vereist dat alles helemaal opnieuw wordt geschreven, Maven vertrouwt op conventies en biedt vooraf gedefinieerde commando's (doelen).

Simpel gezegd, Maven stelt ons in staat om ons te concentreren op wat onze build zou moeten doen, en geeft ons het kader om het te doen. Een ander positief aspect van Maven was dat het ingebouwde ondersteuning bood voor afhankelijkheidsbeheer.

Het configuratiebestand van Maven, dat instructies voor het bouwen en het beheer van afhankelijkheden bevat, wordt volgens afspraak pom.xml. Daarnaast schrijft Maven ook een strikte projectstructuur voor, terwijl Ant ook daar flexibiliteit biedt.

Hier is een voorbeeld van een pom.xml bestand voor hetzelfde eenvoudige Java-project met de Hallo Wereld hoofdklasse van vroeger:

 4.0.0 baeldung maven Voorbeeld 0.0.1-SNAPSHOT Maven voorbeeld junit junit 4.12 test 

Nu is de projectstructuur echter ook gestandaardiseerd en voldoet deze aan de Maven-conventies:

+ --- src | + --- hoofd | | + --- java | | | \ --- com | | | \ --- baeldung | | | \ --- maven | | | HelloWorld.java | | | | | \ --- bronnen | \ --- test | + --- java | \---middelen

In tegenstelling tot Ant is het niet nodig om elk van de fasen in het bouwproces handmatig te definiëren. In plaats daarvan kunnen we eenvoudig de ingebouwde opdrachten van Maven aanroepen.

We kunnen de code bijvoorbeeld compileren door het volgende uit te voeren:

mvn compileren

In de kern, zoals vermeld op officiële pagina's, Maven kan worden beschouwd als een raamwerk voor het uitvoeren van plug-ins, aangezien al het werk wordt gedaan door plug-ins. Maven ondersteunt een breed scala aan beschikbare plug-ins, en elk van deze kan aanvullend worden geconfigureerd.

Een van de beschikbare plug-ins is Apache Maven Dependency Plugin met een kopie-afhankelijkheden doel dat onze afhankelijkheden naar een opgegeven map kopieert.

Om deze plug-in in actie te laten zien, laten we deze plug-in opnemen in ons pom.xml bestand en configureer een uitvoermap voor onze afhankelijkheden:

   org.apache.maven.plugins maven-dependency-plugin kopieerafhankelijkheden pakket kopieerafhankelijkheden doel / afhankelijkheden 

Deze plug-in wordt uitgevoerd in een pakket fase, dus als we draaien:

mvn-pakket

We zullen deze plug-in uitvoeren en afhankelijkheden naar de map target / dependencies kopiëren.

Er is ook een bestaand artikel over het maken van een uitvoerbare JAR met verschillende Maven-plug-ins. Voor een gedetailleerd Maven-overzicht, bekijk bovendien deze kerngids over Maven, waar enkele van de belangrijkste functies van Maven worden onderzocht.

Maven werd erg populair omdat build-bestanden nu gestandaardiseerd waren en het aanzienlijk minder tijd kostte om build-bestanden te onderhouden in vergelijking met Ant. Hoewel Maven-configuratiebestanden meer gestandaardiseerd zijn dan Ant-bestanden, hebben ze nog steeds de neiging om groot en omslachtig te worden.

De strikte conventies van Maven brengen de prijs met zich mee dat hij een stuk minder flexibel is dan Ant. Het aanpassen van doelen is erg moeilijk, dus het schrijven van op maat gemaakte scripts is een stuk moeilijker in vergelijking met Ant.

Hoewel Maven een aantal serieuze verbeteringen heeft aangebracht om de bouwprocessen van applicaties eenvoudiger en meer gestandaardiseerd te maken, heeft het nog steeds een prijs omdat het veel minder flexibel is dan Ant. Dit leidde tot de creatie van Gradle die het beste van twee werelden combineert: Ant's flexibiliteit en Maven's functies.

4. Grijpen

Gradle is een afhankelijkheidsbeheer en een build-automatiseringstool die werd gebouwd op de concepten van Ant en Maven.

Een van de eerste dingen die we kunnen opmerken over Gradle is dat het geen XML-bestanden gebruikt, in tegenstelling tot Ant of Maven.

In de loop van de tijd raakten ontwikkelaars meer en meer geïnteresseerd in het hebben en werken met een domeinspecifieke taal - die, simpel gezegd, hen in staat zou stellen problemen in een specifiek domein op te lossen met behulp van een taal die is afgestemd op dat specifieke domein.

Dit werd overgenomen door Gradle, die een DSL gebruikt op basis van Groovy of Kotlin. Dit leidde tot kleinere configuratiebestanden met minder rommel, aangezien de taal specifiek was ontworpen om specifieke domeinproblemen op te lossen. Het configuratiebestand van Gradle wordt volgens afspraak build.gradle in Groovy, of build.gradle.kts in Kotlin.

Merk op dat Kotlin betere IDE-ondersteuning biedt dan Groovy voor automatische aanvulling en foutdetectie.

Hier is een voorbeeld van een build.gradle bestand voor hetzelfde eenvoudige Java-project met de Hallo Wereld hoofdklasse van vroeger:

pas plug-in toe: 'java' repositories {mavenCentral ()} jar {baseName = 'gradleExample' version = '0.0.1-SNAPSHOT'} afhankelijkheden {testImplementation 'junit: junit: 4.12'}

We kunnen de code compileren door het volgende uit te voeren:

gradle klassen

In de kern biedt Gradle opzettelijk heel weinig functionaliteit. Plug-ins voegen alle handige functies toe. In ons voorbeeld gebruikten we Java plug-in waarmee we Java-code en andere waardevolle functies kunnen compileren.

Gradle gaf zijn bouwstappen de naam "taken", in tegenstelling tot Ant's "doelen" of Maven's "fasen". Met Maven hebben we Apache Maven Dependency Plugin gebruikt, en het is een specifiek doel om afhankelijkheden naar een opgegeven map te kopiëren. Met Gradle kunnen we hetzelfde doen door taken te gebruiken:

taak copyDependencies (type: Copy) {from configurations.compile into 'afhankelijkheden'}

We kunnen deze taak uitvoeren door het volgende uit te voeren:

gradle copy Afhankelijkheden

5. Conclusie

In dit artikel hebben we Ant, Maven en Gradle gepresenteerd - drie Java-buildautomatiseringstools.

Het is niet verrassend dat Maven tegenwoordig het grootste deel van de markt voor bouwgereedschap in handen heeft.

Gradle heeft echter een goede acceptatie gezien in complexere codebases, om de volgende redenen:

• Veel open-sourceprojecten zoals Spring gebruiken het nu
• Het is voor de meeste scenario's sneller dan Maven, dankzij de incrementele builds
• Het biedt geavanceerde analyse- en foutopsporingsservices

Die Gradle lijkt echter een steilere leercurve te hebben, vooral als je niet bekend bent met Groovy of Kotlin.

De volgende » Aangepaste Gradle-plug-ins schrijven « Vorige introductie tot Gradle