Již hodně dlouho se na mě ze všech stran valí, že Ant je překonaný a že bychom měli používat Maven. Jistě Maven přináší spoustu zajímavých myšlenek, především zavedl jednoutnou strukturu projektů a správu závislostí. Ovšem přinesl i spoustu problémů, jako pevně daný build cycle či buildování multi-projektu.
Na trhu open source projektů se objevuje nový hráč, který si řadu těchto nešvarů bere za své a snaží se je napravit. A o jakém projektu, že píši? O projektu Gradle. Gradle je teprve ve verzi 0.2, ale vyvíjí se mílovými kroky.
A co je to převratné, co mě zaujalo. Build skripty se píší v jazyce Groovy. Má to řadu výhod, skript je programován, je možné používat (zavolat) jakýkoliv kód (díky Groovy, jakýkoliv Javovský kód). Navíc je možné opakující se části volat jako funkce (které se dají vytvářet přímo v build scriptu). Bezvadná integrace s Antem. Kolik z nás má v Antu poměrně složité skripty na generování kde čeho. Jejich převod pod Maven je hotovým peklem. Dále build multi-projektu v maven jde pouze z kořenového projektu, díky čemuž se buildu celý multi-projekt. V Gradle je možné multi-projekt build spustit z libovolného projektu a tím se buildují jenom ty podprojekty, které jsou potřeba.
Konvence ohledně build cycle jsou v Gradle definovány pomocí pluginů. Tj. pokud použiji plugin java, pak je nadefinován konkrétní build cycle. Tento může být dle potřeby modifikován, buď jiným pluginem (např. plugin groovy) či samotným build skriptem. To znamená konec dvojí pouštění testů, aby mohl vzniknout Cobertura code coverage.
A co zatím chybí. Je toho stále dost, není nativní podpora pro TestNG, Coberturu. Neexistují integrace s IDE.
Zatím jsem lákání Mavenu odolal a doufám, že Gradle dospěje a pomůže mi vyřešit problémy, které s Antem máme. Hrozně nerad bych naše skripty převáděl a ladil v Mavenu.
21. července 2008
Konečně build systém na úrovni - Gradle
Přihlásit se k odběru:
Komentáře k příspěvku (Atom)
Příspěvky
9 komentářů:
Je potreba si uvedomit, ze Ant a Maven je o uplne jine filozofii. Nejde proste aplikovat Ant na Maven a naopak. Co naopak lze, je doplnit Maven o Ant skripty, ktere slouzi k specialnim uloham. Mame v Mavenu opravdu velky projekt cca. 150 modulu, budildime installator, EAR do nej WAR, EJB moduly atd. a toho Antiho skriptu je tam poskrovnu.
Já nehodnotím filosofii. Co se mi na Mavenu líbí, je definice struktury adresářů projektu. Ta se dá použít i bez něj. Dále sjednocení life cyclu projektu a to se dá v Gradle také, protože plugin nadefinuje life cycle. A konečně správa závislostí, kterou opět Gradle řeší také.
V našem projektu máme genrování PDFek, HTML nápovědy a podobných věcí, což si převést do Mavenu nedokážu představit. Navíc zprávy na Maven, co se jeho používání týče, nejsou čistě pozitivní. Znám pár lidí co od něj uteklo. A např. používájí pouze jeho správu závislostí.
A známý problém s Coberturou v Mavenu nemusím už snad ani zmiňovat. Navíc některé pluginy mají naprostu příšernou odezvu na požadavky či řešení bugů.
Řešení problémů je vždy na půl dne minimálně, protože dokumentace je nic moc. Já nevím, mě se moc nechce, se do něčeho takového pouštět. Nejsme firma o 20 vývojářích, které se vyplatí jeho použití i za cenu specialisty na Maven.
Mohu se zeptat jestli se takto da pospsat projekt, nebo se tim popisuje jenom build cyklus?
Protoze ve chvili kdyz k vyvoji pouzivaji vasi vyvojari vice nez jedno IDE, je potreba mit moznost popisovat produkt v jednotne forme. K tomu se Maven skvele hodi, pro kazde IDE se daji vygenerovat nastaveni v jeho formatu. Nastaveni code-style, zavyslosti jar souboru, projektu atd. Nastaveni testovaciho toolu, nastaveni debug serveru (treba pro spousteni debugu pres Tomcat, nebo Jetty)
Mam totiz pocit, ze ten nastroj nedeklaruje vlastnosti projektu. Ale pouze programuje build, coz bych rekl, je krok zpatky.
Jestli vás správně chápu, pak se v Gradle projekt popisuje méně než v Mavenu. Ale ...
Gradle má v TODO úkol generovat soubory pro jednotlivá IDE, protože spravuje závislosti a toto je přirozeným vyústěním této funcionality.
Co se popisu projektu, ve smyslu WWW stránek, vývojářů atd. pak to Gradle neobsahuje, ale je nutno brát v potaz jak mladým je nástrojem a čert ví, co bude umět ve verzi 2.0 (nený je verze 0.2). Vývoj probíhá dostatečně rychle, takže se možná dočkáme spousty věcí. V tuto chvíli je Gradle spíš hračka, kterou je nutno ještě hodně naučit ... ale potenciál v něm jistě je.
Mozna jsem uchylak, ale me Ant plne vyhovuje. Od Mavenu2 jsem s krikem utekl. A Gradle je mozna fajn, jen zbyva implementovat 'tohle' a 'tohle' a mozna 'tohle'.
Na cokoliv slozitejsiho si pisu tooly v jave a volam je z Antu.
4jira: No ale tady spise jde o filozofii tohoto programu. Pokud jeho filozofii je programovat build, tak se z neho budou informace spatne nacitat.
Samozrejme, ze pokud chcete "jenom" build system, pak je dobry ANT, protoze v nem naprogramujete, co chcete.
Maven je dobry na spravu zivotni cyklus projektu. Naprosto striktne oddeluje definici jednotlivych fazi zivotniho cyklu a metodiku jak z tehto nastaveni ziskat pozadovany vystup.
Podstatne je to, ze XML zde funguje jenom k deklaraci. A to daleko vice veci, nez jenom zavislosti projektu. Umoznuje deklarovat nastaveni testu atd.
Tato deklarace muze byt pouzita nejenom pro spusteni primo z Maven, ale take pro ziskani nastaveni pro vase IDE.
Maven vas svym zpusobem nuti to roztrhnout deklaraci a popis algoritmu. Pokud ale muzete bastlit deklaraci a algoritmy dohromady, bude pouziti jine, nez k buildu, velice slozite.
P.S.: vzhledem k tomu, ze sem autorem Goalu, ktery generuje z pom.xml nastaveni projektu pro Emacs JDEE, vim jaka je to pomoc. Kdyz zpustite jeden skript a mate kompletni nastaveni vcetne maildiskuze, bugizlly, checkstylu i skupin testu.
Ted delam ve firme kde se pouziva ANT a tam nic takoveho neni mozne. Takze sem rezignoval, na to pouzivat svoje IDE, protoze nez bych provedl vsechna nastaveni, porodil bych. Nastaveni je distribuovane pro eclipse a par developeru venovalo cas tomu si udelat nastaveni pro sve IDE, ale pokud nemam tyden nastavovat, tak musim vzit Eclipse :(
to benzin: Bavíme se o něčem, co je těžké potvrdit nebo vyvrátit, protože Gradle má tyto věci zatím v TODO. Pokud se dostanu tak daleko, že jej budu sledovat i nadále, pak se o tom jistě rád v budoucnu rozepíšu, zatím se mi jeví lepší než Maven v tom, že řadu věcí standardizuje, ale nezamyká dvířka pro jejich změnu, což mě na Mavenu vadí. A ukecanost v pom.xml je také větší než v Gradlu.
Gradle taky fandím. I pokud jde "jenom" o build systém, pořád je to obrovský krok dopředu, skriptování v Antu nebo v Mavenu 1 je strašlivé.
4ladislav thon: Skriptovani v Mavenu, IMHO je presne to co se v nem nema delat.
Funkcni veci zarizuje Goal a ten muze nacitat libovolne externi skripty. Ale neni to skriptovani v Mavenu jako takovem.
Okomentovat