Varför jag gillar Gradle

I begynnelsen var det make. Dvs i Javas barndom (a.k.a. 90-talet) fanns bara Unix/Linux make för att bygga/sammanfoga programsystem. Detta var ju ett problem för ett plattforms-oberoende språk som Java.

Apache Ant

Kring millennieskiftet och när XML var som hetast, kom så Ant. Via en konfigurationsfil i XML kunde man beskriva en stor mängd byggtekniska steg. Allt från att kompilera ett gäng Java klasser, peta in dem i en JAR fil, stoppa in denna plus mycket annat webbrelaterat i en WAR fil, hämta eller lämna data i en SQL databas, koka kaffe - äh, nä kanske inte just det, men mycket annat.

Ant tog Java världen med storm. Ant växte sig större och större, och en dag var Ant jättestor. Medan de andra ..., nä stopp - tillbaka i spåret. Det som vi alla noterade med varierande grad av frustration, var att varje gång man kom till ett nytt projekt så behövde man läsa in sig på bygg dokumentationen.

Hur gjorde man nu för att bygga systemet? Var det ant build, ant make, ant package, ant assembly, ant doit, ant fixit, eller bara kort och gott ant? Och, hur körde man de där unit testen? Och var ska man lägga alla 3-parts JAR filer? Och hur ska dessa packas upp med rätt namn-standard? Åh, föresten; var i hela friden ska jag lägga mina Java klasser? Alla som var med, minns detta.

Apache Maven

Så kom Maven i 2004 och gjorde rent hus med Ant. Maven innebar en smärre revolution i vår del av den programmerar-tekniska världen, genom att införa (1) standardisering och (2) konfigurering via konventioner, samt störst av dem alla, (3) automagisk hantering av 3-parts JAR filer.

Dessutom avslutade Maven debatten huruvida man har tid med dokumentation eller ej. Alla kunde nu köra kommandot mvn site och få den mest tjusiga webbplats med JavaDocs för alla klasser, unit-test rapporter, källkods-listningar, listning av alla 3-parts beroenden, instruktioner om hur och var man checkade ut koden och mycket annat.

Standardisering och konfigurering

Förvånansvärt snabbt lärde vi oss alla att placera Java klasser under src/main/java och test-klasser under src/test/java och resurs-filer under src/main/resources. Samt, ville man kompilera skrev man mvn compile, att bygga hela systemet var lika enkelt med mvn package och då kördes dessutom alla unit-test som en extra bonus.

Transitiva beroenden

Ovanstående var fantastiskt, men dependency mekanismen var gudomlig. Genom att bara skriva några rader XML i Mavens konfigurationsfil pom.xml, så utförde Maven ett mirakel:

Första gången, man sen körde ett Maven kommando, så laddades JAR filerna för alla beroenden ned och lagrades på den egna hårddisken, inklusive alla deras beroenden i sin tur. Detta kallas med ett mer akademiskt uttryck; den transitiva slutningen av beroende-grafen.

Maven, hammaren och skäran

Nu var förvisso inte allt frid och fröjd. Med tiden utvecklades en hat-kärlek till Maven. Så länge man höll sig på den "enda vägen" så var allt frid och fröjd, men nåde den som försökte ändra på delar av den POMetariata byggprocessen och lägga till byggsteg eller något så kontra-revolutionärt som att generera mer än en artifakt. Då väntande evig förvisning på den Sibiriska XML tundran, med otaliga strapatslika sökningar i mängder av Maven-plugins skrifter.

Under tiden på en annan planet

Redan tidigt under språket Groovys utveckling, så var Ant en integrerad del av språket. Efter att först skapat ett AntBuilder objekt, kunde man sen anropa vilka Ant uppgifter (tasks) som helst. Den stora poängen var kombinationen av Ant rikhaltiga flora av uppgifter, med ett programspråk som Groovy. Med lätthet kunde man nu skriva Ant build uttryck som helt enkelt inte var möjliga att formulera via XML.

Detta medförde att Ant fick en renässans inom Groovy världen.

GAnt landar

Snart utvecklades an fullfjädrad ersättare för Ant, nämligen GAnt. Det gick nu att skriva byggskript med Ant, men med Groovy syntax. 

Är du intresserad av ett lite större GAnt skript, så skrev jag en blogg-post för några år sedan om hur man genererar flera Android APK filer (app:ar) från samma kodbas. Något som inte var möjligt med Googles egna Ant skript, som följer med när man skapar ett nytt Android projekt.

Emellertid, fanns det ett grundläggande problem med GAnt, vilket var exakt samma som för Ant. Ingen standardisering och ingen automagisk hantering av 3-parts JAR filer.

Gradle

Det var detta Hans Dockter funderade över på en Groovy & Grails konferens. Resultatet blev byggverktyget Gradle som kombinerar det bästa från Ant, GAnt och Maven, men undviker deras tillkortakommanden.

Om Ant representerar första generations bygg-verktyg och Maven andra generations, så utgör Gradle den tredje generationens bygg-verktyg, för Java, Groovy, Scala, C++ och mycket annat.

Gradle använder sig av samma konventioner som Maven, men tvingar inte användaren att bara generera en artefakt (JAR, WAR, EAR, ...) per projekt. Gradle använder inte XML som representation av bygg-skript, utan Groovy vilket på en gång gör Gradle betydligt mer kraftfullt än Ant och Maven någonsin varit. Behöver man lägga in t.ex. villkorade bygg-delar så är det hur enkelt som helst, vilket - som alla som prövat - i Ant och Maven inte är helt trivialt för att uttrycka sig milt.

Att bygga ett standard Java system, utan krusiduller, så behöver man bara en enkel rad i sitt Gradle bygg-skript (build.gradle)

apply plugin: 'java'

Och man kompilerar med kommandot

gradle compile

Samt, bygger en JAR fil och kör alla test, med kommandot

gradle build

Ett av mina Gradle projekt

Jag har utvecklat en del open-source plugins för CA-Wily Introscope, som används av kunder på i Sverige och på många ställen runt jordklotet. I höstas, gjorde jag en anpassning för en kund i Sundsvall och passade då på att byta från kombinationen Maven + Ant, till blott Gradle. Jag använde förut Maven för den reguljära bygg-biten, men Ant för att generera och instrumentera en Introscope-Agent som applicerades på ett funktions-test.

Nu, med Gradle var det hur enkelt som helst att kombinera detta i ett enda bygg-skript. Så här ser detta ut (taget från min publika GitHub repo ExpressionTracer).

Jag tänkte inte gå igenom allting, utan bara peka på vissa intressanta delar. Projektet använder 3-parts JAR filer hämtade både från Maven Central och lokalt från min hårddisk (eftersom Agent.jar är en kommersiell komponent). Något man svårligen kunde göra i Maven. Den sista delen är GAnt liknande kod för att hantera funktionstestet. Något liknande är helt omöjligt att åstadkomma i Maven, såvida man inte implementerar en egen Maven-plugin.

Till sists

Om du inte kikat på Gradle hittills, så är det hög tid nu. 

Om du fortfarande bygger m.h.a. Ant men funderar på att byta till Maven; hoppa då över andra generationen och gå direkt till tredje generationens bygg-verktyg.

Om du bygger ditt system i Maven och tycker det börjar bli lite tungrott; kika då på Gradle.

Vill du att vi på Informator ska arrangera ett frukost-seminarium om Gradle, ange det i en kommentar nedan.