tifyty

pure Java, what else ?

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.

16 responses to “Gradle, ant és maven

  1. Gábor Lipták január 22, 2014 12:40 du.

    Alapvetően a Gradle-el az a bajom, ami a groovyval. Nagyon könnyű benne olyan kódot írni, amit senki nem ért meg (beleértve az írót magát) 2 hónap múlva. Debuggolni bár lehet, de azért nem leányálom még. Nálunk most vannak Groovyban írt Maven pluginok, és vegyesek az érzelmeim velük kapcsolatban. A szoros ANT integráció mindenképpen előny, hiszen ugyanazt amit Antal megcsinál 5 sorban, egy darabig írogathatnám sima Jávában. De a kód nagyon kusza.

    Én egyelőre még nem mennék el Gradle irányba, hacsak nem nagyon muszáj.

    • Peter Verhas január 22, 2014 12:53 du.

      Minden eszköz (nyelv) esetében nem az számít, hogy mekkorát lehet vele alkotni, hanem az, hogy mekkorát lehet bukni.

      Ezért nem javasolt a motorozás sem. Igaz, hogy egy Talmácsi Gábor csodákat tud művelni ha motor van alatta, de Te (junior programozó) meg fogsz halni.

      • mhmxs január 23, 2014 9:20 de.

        Aktívan fejlesztek Groovy alkalmazást (igazából Grails). Megmondom őszintén a teljesítménnyel nincs nagy problémánk, ugyanis kutyaközönséges WAR-fájlt készítünk, amit megetetünk az éles Tomcattel, és az egészet megfelelő cachelési stratégiával egészítünk ki. És magával a nyelvvel sincs komolyabb bajom, leszámítva, hogy néha megviccelnek a generikus típusok, amike a fordító ignorál ha épp első nekifutásra nem tudta kitalálni minek is kéne ott lennie, futásidőben meg ugye… De ehhez a zen állapothoz az alábbit kell tennem: Junior kollégákat kéztöréssel kell fenyegetni (és néha beváltani az igéretet ha úgy hozza a sors, ne csak üres fenyegetés legyen) ha nem definiálják a típusokat szorgalmasan, ha nem követik a Java naming and coding sztenderdeket. Kezdő, és lusta programozóknak egyértelműen nem való a nyelv, de ha valaki képes a könnyű utak csábítása ellenére komolyan és éretten gondolkodni (vagy csak fél a kéztöréstől), akkor minden eszköz megvan a Groovyban, hogy minőségi kódot állítson elő (tudom, hogy a vaskalapos Javasok ezzel nem fognak egyet érteni, és azt sem mondom, hogy nincs igazuk, de mindkét nyelvnek megvannak az előnyei és hátrányai. valamit valamiért).

      • Gábor Lipták február 21, 2014 9:26 de.

        Mit is mondhatnék erre? Ahogy a kéményseprő mondaná: a koromhoz képest jól nézek ki.

  2. Péter András Szászvári január 22, 2014 12:45 du.

    Ha az ember azt gondolja, hogy a Maven egy nem teljesített ígéret (nem egyszerű, nem csinálja amit várunk tőle, ha elbukik nagyon nehéz kijavítani, stb.) és az ember olvas a Gradle-ről és azt várja tőle, hogy könnyebbé teszi az életet a Mavennel, azaz úgy viselkedik mint egy Maven hekker aki lefordítja a kívánságaimat és addig buherálja a Mavent amíg az tényleg nem működik, szóval ha az ember ilyesmit vár tőle, téved?

  3. Verhás István január 22, 2014 2:42 du.

    Az ivy repository és a maven repository két különböző dolog?
    “Apache Ivy is compatible with maven 2 metadata” http://ant.apache.org/ivy/m2comparison.html

    Szerintem az is egy lehetséges irány a jövőben, hogy a nem standard dolgokat megcsináljuk groovy-ban és amikor már sokszor/sokan megcsináltuk akkor közösen megegyezünk, hogy mi legyen a szabványos és azt beépítjük a maven-be. Miért kell ehhez új eszköz? Vagy csak az öregedés mondatja ezt velem?

    • Peter Verhas január 22, 2014 5:06 du.

      Nagyon sok fejlesztőnek nem tetszik az ANT. Nagyon sok fejlesztőnek nem tetszik a Maven. Elegük van az XML szerkesztésből. Nem hisznek abban, hogy egy konvenció (pl. dependency conflict resolution) beégetve, átírhatatlanul minden esetben jó.

      Olyan eszközt akarnak a build-re, amelyiket használhatnak a konvenciók mentén, de ha kell akkor eltérhessenek attól. Nem akarnak a build eszközzel sokat foglalkozni, végezze a dolgát. Nem akarja senki leírni ezredszer is, minden egyes projektben, hogy ezt is úgy kell bildelni, mint ahogy millió más projektet a világon. De ha nem úgy kell valamiért, akkor nem akar senki napokat azzal tölteni, hogy plugint keres, próbálja megérteni a dokumentációját, ami nincs, vagy rosszabb esetben ezer évvel ezelőtti verzióról szól, debuggolni a plugint, és végül két nap után megírni nulláról egy nap ráfordítással. Erre 30 perc van, a projekttel kell foglalkozni, nem a build tool-lal.

      Ezért kell maven és ant után gradle. Sokan mondják, és ha sokan mondják, el kell gondolkodni rajta. Hinni semmiben nem kell. Amúgy meg minek az ANT? Minek a Maven? Mindek a Java? Van vi, FORTRAN és make.

      • Peter Verhas január 22, 2014 5:14 du.

        >Az ivy repository és a maven repository két különböző dolog?

        Pont az általad adott linked levő dokumentum írja le, hogy mennyire más. És az csak a feature set. A struktúra, a directory elnevezések sem azonosak, bár azok éppen lehetnének, de nem.

      • tamasrev január 30, 2014 4:01 du.

        Na, ezt, így, csak nagyobb betűkkel ki kéne tacepaózni minden szoftvercég irodájába

    • aszomor február 9, 2014 12:56 du.

      Nekem tetszik a felvetés mert az src/main/java könyvtárba a java forrást maven nélkül is beteheted, a lényeg, hogy legyen koncepció/standard a fejlesztéskor, azonban kétség kívül sok időt takarítasz meg, ha ezt már készen kapod. Én használtam az ANT/Ivy párost és nagyon meg voltam elégedve vele. Sőt az Ivy .Net alatt is elérhető, bár most már a Nuget egyeduralkodóvá vált ott viszont most meg a Nuget érhető el Java-ból is.

  4. mig8 február 16, 2014 4:44 du.

    Nekem semmi bajom a Maven-nel alapvetően. Igaz, néha előjönnek a bugjai. De alapvetően gyorsan lehet vele dolgozni, de akár kísérletezni is. Végülis nem az a célja senkinek se, hogy sok időt töltsön a buildeléssel, hanem – ahogy egy kollégám mondaná – hogy “műköggyön”. És ebben a Maven szerintem messze a leghatékonyabb.

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s

%d blogger ezt kedveli: