Sissejuhatus ehitusinstrumentidesse

Sissejuhatus

Kui Java projekt koosneb ühest failist, on selle kompileerimine ja käivitamine lihtne, tuleb lihtsalt käivitada javac ja seejärel java käsklus käsurealt. Kuid reaalsed projektid ei koosne ainult ühest failist ning on palju kompleksemad. Need võivad endas sisaldada kümneid kuni tuhandeid lähtekoodi faile, sõltuda välistest teekidest, vajada automaatteste ning lõpuks toote levitamiseks olla kokku pakitud ühte JAR-faili.

Kõike seda käsitsi tehes tuleb alla laadida JAR-failid, hallata classpath’e, kompileerida faile õiges järjekorras ning iga kord meeles pidada täpne käskude jada. See toimib väikeste näidisprojektide puhul, kuid laguneb kohe projekti kasvades.

Ehitusinstrumendid (build tools) automatiseerivad kogu selle protsessi. Need võimaldavad projekti korduvalt kompileerida kindlate ette määratud protsetuuride järgi.

Kolm enimlevinud probleemi

Ehitusinstrumendid lahendavad kolme peamist probleemi, mis esinevad igas mittetriviaalses projektis.

Sõltuvuste haldamine

Oletame et projekt sisaldab endas Google Gson teeki JSON vormingu töötlemiseks. Need teegid omakorda sõltuvad teistest teekidest - selline sõltuvusahel on transitiivne.

Ilma ehitusinstrumendita peaksid iga JAR faili käsitsi alla laadima, asetama selle õigesse kataloogi ning lisama selle projekti classpath'i. Kui lisatud teeki uuendataks, peaksid seda protsessi uuesti kordama. Lisaks tekib ka probleem siis, kui kaks erinevat teeki kasutavad üht ja sama sõltuvust, kuid erinevate versioonidega. Sellist olukorda isepäi on raske tuvastada ning veel raskem parandada (näiteks olukord kus üks teek sõltub mingist vanast funktsionaalsusest, mida enam ei ole).

Ehitusinstrumendid haldavad sõltuvusi automaatselt. Arendaja peab lihtsalt deklareerima, mis teeke on vaja (nimi ja versioon) ning instrument hoolitseb selle allalaadimise ja muude eelnevalt mainitud probleemidega tegutsemise eest.

Ehitusprotsessi elutsükkel

Lähtekoodi kompileerimine on vaid üks samm. Tüüpiline ehitusprotsess hõlmab endas:

1. Põhilähtekoodi kompileerimist
2. Testlähtekoodi kompileerimist
3. Testide käivitamist
4. Tulemuse pakkimist JAR-failiks
5. Soovi korral raportite genereerimist (koodikatvus, staatiline analüüs)

Iga samm sõltub eelnevast. Ehitusinstrument määratleb nende järjestuse ja tagab, et sammud käivitatakse õiges järjekorras. Selle asemel, et meelde jätta ja sisestada viis eraldiseisvat käsku, piisab ainult ühest.

Korduvkasutatavus

Kui projekti on võimalik edukalt valmis ehitada ühes masinas, ei tohiks see ka probleem olla ka mõne teise masina peal (või kasvõi teatud aja (nt: 6 kuu) pärast).

Ehitusinstrumendid saavutab seda fikseerides:

• täpsed sõltuvuste versioonid
• kompileerimiseks kasutatava Java versiooni
• ehitusprotsessi sammud

Igal instrumendil on oma konfiguratsioonifail (nt: pom.xml või build.gradle), need failid on ainsad tõeallikad selle kohta, kuidas antud projekti ehitama peaks.

Ajaloost lühidalt

Java ehitusinstrumendid on aja jooksul arenenud, kus iga järgmine põlvkond lahendab eelmise puudused.

Käsitsi kompileerimine (javac + java) töötab ühe faili puhul, kuid ei skaleeru.

Apache Ant (2000) tutvustas protsessi XML-põhised skriptid. Tekkis võimalus määratleda sihtprotsesse nagu compile, test ja jar ning Ant käivitas need. Sisuliselt võimaldad need käivitada ainult teatud etappe. Ant-i miinuseks oli tollel ajal see, et sellel puudus võimalus hallata sõltuvusi ehk JAR faile tuli jätkuvalt käsitsi alla laadida. Samuti Ant ei järginud ühtegi kokkulepitud tava projekti struktureerimise kohta, mis tähendas, et iga projekt defineeris oma ehitusprotsessi nullist.

Apache Maven (2004) tutvustas kaht uut võtet: kokkulepped eelistatud konfiguratsioonile (convention over configuration) ja automaatse sõltuvuste halduse. Kõik Maveni projektid järgivad standardset kataloogistruktuuri (src/main/java ja src/test/java). mistõttu enamik projekte vajab minimaalset konfiguratsiooni. Sõltuvused deklareeritakse pom.xml failis ning laetakse automaatselt Maven Centralist alla.

Gradle (2012) säilitas Maveni sõltuvuste haldamise süsteemi, kuid asendas XML-põhise skripti Groovy (ja hiljem Kotlin) põhise skriptiga. Samuti lisandusid inkrementaalsed ehitusetapid ja puhvrifunktsionaalsus, mis muutsid suurte projektide ehitamise oluliselt kiiremaks. Gradle on Androidi arenduse vaikimisi ehitusinstrument ning seda kasutatakse laialdaselt kaasaegsetes Java projektides.

Maven Central

Kõik kaasaegsed ehitusinstrumendid (Ant koos Ivy-ga, Maven, Gradle) on suutelised alla laadima oma sõltuvusi Maven Central-ist. See on kõige suurim avalik Java teekide repositoorium.

Igal teek Maven Centralis sisaldab järgmisi tunnuseid:

• groupId — teegi looja (e.g., com.google.code.gson)
• artifactId — teegi nimi (e.g., gson)
• version — väljalaske versioon (e.g., 2.10.1)

Nende kolme tunnuse kooslusel tagatakse teekide unikaalsus. Kui konfiguratsioonis deklareerida mõni sõltuvus, siis ehitusinstrumendid kasutavad neid tunnuseid, et õige JAR fail üles leida ja alla laadida.

Maven Centraliga saate tutvuda järgneval aadressil: https://central.sonatype.com

Kokkulepitud projekti struktuur

Nii Maven kui ka Gradle eeldavad, et projekti struktuur oleks vaikimisi järgmine:

project/
├── src/
│   ├── main/
│   │   └── java/          <- production source code
│   │       └── com/example/
│   │           └── App.java
│   └── test/
│       └── java/          <- test source code
│           └── com/example/
│               └── AppTest.java
├── pom.xml                <- Maven config (or build.gradle for Gradle)

See kokkulepe tähendab, et sa ei pea tööriistale ütlema, kus sinu kood asub. Kui järgid kokkulepet, jääb konfiguratsioon minimaalseks.