tifyty

pure Java, what else ?

Havi archívumok: január 2014

Gradle, ant és maven

Amikor először, talán két éve, kipróbáltam a gradle építési eszközt (build tool) azt találtam, hogy a groovy használata miatt lassú, és nem igazán jött át, hogy mi olyan nagy truváj benne. Az volt a gondolatom, hogy megpróbáltak egy ANT Maven keveréket létrehozni, amelyik amolyan “best of both word” tool akar lenni.

Én soha nem dolgoztam addig ANT-tal, és ezt az állapotomat (ant szűz, vagy szűz hangya?) azóta is sikerült valahogy megőrizni. Ezért aztán nem is nagyon ellenkeztem a maven “convention over configuration” megközelítése ellen. Nincs is azzal semmi gond, és a legnagyobb ellenkezés általában abból fakad, hogy a programozó, ha egyszer megszokta, hogy Java-ban programoz, ami imperatív nyelv, akkor a build tool-nak is szeretni megmondani, hogy az mit csináljon. Különben is, hogy jön egy maven ahhoz, hogy kitalálja, hogy tegyem az src/main/java könyvtárba a java forrást. Mi a fenének ez a mély hierarchia? Nincs is más forrásom, csak java, azt a néhány resource fájlt is be tudom oda pakolni, és mi az a main egyáltalán? Úgyse írunk unit tesztet, az csak az amatőröknek való, a profik hibátlan kódot írnak. (Ha ismersz, tudod, hogy mikor tréfálok, ha nem, akkor meg használd az agyad, és ne higgyél el mindent amit a felnőttek mondanak. Apu nem azért fekszik anyun, hogy helyet spóroljanak.)

No, de akár tetszik, akár nem, el kell ismerni, hogy a maven nem söpörte ki az ant-ot, és a hangyák az elmúlt pár évben nem jutottak a dinoszauruszok sorsára, és nem haltak ki. Szépen megpróbálták felvenni a versenyt a maven vitathatatlan erősségeivel (pl. dependency management és itt az ant oldaláról az ivy-ra gondolok), és ment tovább a bevált, és elfogadott hagyományos command driven build-elés.

Akkor jött a gradle, és úgy tűnt, hogy csak annyit mond, hogy ne erőltessük a fejlesztőkre a konvenciókat, ha annyira nem akarják. Persze az okosabbja akarja, azokat is szolgáljuk ki, de legyen parancs orientált is. És ha már programozók vagyunk, akkor ne kelljen XML fájlokkal borzolnunk a torkunkat, jó lesz valami programozási nyelv is, például a zseniális groovy (ugye mindenki tudja, hogy mikor viccelek). És lassú volt, mert egy groovy-t beindítani összemérhető egy dízel ZIL (nem Jason) tehergépkocsi beindításával -20C fokban a laktanyában (1985. február: meg lehet nézni a meteorológiai archívumokat, az a hideg felolvadhatatlanul belém égett).

Így aztán kipróbáltam, és ment a többi, “erre még figyelni kell a jövőben” technológia közé.

Aztán eltelt két év, és most újra elővettem, és egy kicsit másképp látom a dolgokat. Ez a cucc nem arról szól, hogy elegünk van a convention over configuration-ből, és jobb keverni a command driven-t meg a (nem írom le mégyegyszer!) a convention over configuration-t (copy paste volt). Hanem egyszerűen arról, hogy a a convention over configuration-t csak ott lehet használni, ahol már kialakult az általánosan elfogadott iparági best practice. Például a java build-elésnél. Persze lehet ágálni, és soha nem lesz 100% aki az src/main/java-ba rakja a forrásokat, de a maven hatására a legtöbb ez. Az se problámás, hogy az eredmény a target-be kerüljön.

Viszont egy projekt dokumentációs site publikálása már nem olyan egyértelmű. Mehet scp-vel egy web site-ra, pakolhatjuk ftp-vel, vagy git-et használhatunk, github-ot. Vannak hozzá plugin-ok maven-hez, de az már pilótavizsgás. Mondjuk aki Java programozó az eleve pilóta vizsgás, és ha mint Java programozó nézem, akkor egy maven plugin megírása nem olyan nagy kaland. De amikor programozok, akkor nem az eszközeimet akarom fejleszteni, hanem az alkalmazást. És ezek a plugin-ek jók ugyan, de amelyiket használom, az pont azt nem tudja, ami nekem kellene, vagy van benne valami kis bug, amire lehet valami kikerülést csinálni, vagy együt télni vele, de mégsem vagyok boldog.

És a gradle pont azt mondja, hogy keverjük a kettőt. De nem azért, mert nem szeretem a convention over configuration-t (hahh, még mindig benne volt a tészta tárolóban), hanem azért, mert convention-t csak ott lehet használni, ahol van már valami megegyezés. Ellentétben a politikai nagy gyűlésekkel (angolul convention), amelyeket meg éppen azért tartanak, hogy legyen. Ahol nincs, mert még nem forrtak ki annyira az eszközök (SVN, GIT, egyéb infrastrukturális elemek, és akkor melyik, és hogyan), ott jobb ha nem pluginokat kell írogatni, hanem a build leíró nyelvén le lehet írni (groovy-ban), hogy akkor ezt hogyan is képzeltük.

Ennek persze meg van a maga átka. Ha valamit könnyű elkurjantani, azt sokan el fogják. Ha valamihez maven plugint kellett írni, azért aki odáig eljutott, az már átgondolta. ANT scriptet, meg mindenki tud írni. És groovy-t is.

És közben megvilágosodott az is, hogy nem azért nem volt előbb a maven, és nem azért lett az ant olyan, amilyen, mert Jason van Zyl nem világosodott meg hamarabb (illetve azért), hanem mert nem voltak kiforrva azok a szokások, amik lehetővé tették volna.

Hogy mi lesz a jövő? Ki fog halni végre az ant? A maven? Szerintem nem. Bár az ant szerepe egyre kisebb lesz, de az ivy repo-k kikerülhetetlenek. A gradle támogatja is őket, meg az ant taskokat is a groovy-n keresztül. A maven repo is alap, és a maven java build is benne van a gradle-ben. De azt gondolom, hogy a maven szerepe is vissza fog szorulni, és lesz sok kisze kusza gradle projekt, amelyik össze vissza fogja konfigurálni a build-ek nem sztenderd folyamatait (a rosszak meg a sztenderd-et is). Lassan majd kialakulnak azok a sztenderdek, amik a dokumentációról szólnak, site buildelésról, release menedzsmentről, source code versioning-ről stb.

És akkor majd jön egy új tool, ami azt mondja, hogy a gradle rossz és legyen csak convention over configuration megint az addigra kitaposott utak mentén.

Vagy nem.