Apache Ant - jak na složité projekty

Ant je nepostradatelný nástroj při vývoji řešení postavených na Javě, neboť pomáhá plně automatizovat proces kompilace, balení, testování a distribuce produktu.

Článek přináší doporučení (včetně kompletního kompilovatelného příkladu), jak navrhnout antovské skripty v případě složitějších projektů obsahujících více výsledných produktů provozovaných v různých konfiguracích, na kterých pracuje více vývojářů.

Už se vám stalo, že jste si stáhli zdrojovou verzi nějakého populárního open-source produktu v Javě a po hodině marných pokusů o kompilaci jste to nakonec vzdali? Klíčem k tomu, abyste jako autoři ušetřili svým uživatelům podobné rozčarování, je návrh robustního build systému.

Motivací k napsání tohoto článku je autorova zkušenost, že se nevyplácí šetřit čas na vytvoření kvalitního build systému. Tím spíše, pokud je součástí buildu také instalace zahrnující potenciálně nebezpečné operace, jako třeba vymazání databázových tabulek. Myslete na to, že kompilovat projekt mohou kromě vás také jiní programátoři nebo správci systému. Ušetřený čas na ledabyle odvedeném návrhu se vždy i s úroky zaplatí v pozdější fázi projektu. A to zrovna když se vám to bude nejméně hodit - když se něco stane nezvladatelným a je nutné provést refactoring (což v případě, že nejste autorem, může být krajně nevděčná práce).

Cíle návrhu build systému pro typický projekt

Obvykle výsledný produkt projektu obsahuje různé konfigurační soubory, moduly či data, které společně tvoří uníkátní konfiguraci. Záleží to na typu projektu a zvolené architektuře, ale nejčastěji to bude databázový driver, URL databázového připojení a nastavení úrovně logování. Pokud vytváříte k serverové aplikaci síťového GUI klienta (nejlépe s využitím JNLP a Java Web Start technologie), který komunikuje s aplikačním serverem, potřebuje klient znát IP adresu a nastavení poskytovatele adresářových služeb JNDI, se kterým se připojí ke komponentám nebo frontám aplikačního serveru.

Díky dynamické povaze Javy mohou být dnešní systémy za běhu vysoce parametrizovatelné. Všechno je "pluggable" a "customizable". Pokud jste někdy procházeli konfiguračními XML soubory aplikačního serveru JBoss nebo XML soubory s deskriptory J2EE aplikace, tak víte, co to je za monstra. Nic proti tomu. Špatné však je, když je tím zbytečně zatěžován koncový uživatel, byť by to byl programátor.

Technologie Java Web Start umožňuje pouhým otevřením odkazu v HTML stránce nainstalovat a bezpečně spustit plnohodnotnou desktopovou aplikaci. (Stáhne potřebné knihovny na disk a se svolením uživatele vytvoří na ploše a v nabídce programů zástupce pro spuštění. Při dalším spouštění pak ověřuje, zda na webu není novější verze a pokud ano, tak ji automaticky aktualizuje a spustí. To vše bez zásahu uživatele.) Pokud chceme s pomocí této technologie vytvořit naprosto bezúdržbovou aplikaci, musí být veškerá nastavení přibalena k jar souborům aplikace během buildu.

Cíl je tedy jasný: pokud se rozhodnu vydat novou verzi, tak jediné, co si přeji udělat, je na své vývojářské stanici spustit z příkazového řádku povel ant deploy. Nic víc. Tečka. Žádné ruční balení, kopírování, žadná editace konfiguračních souborů, žádné opětovné konfigurování reinstalovaných produktů před či po spuštění.

Zásady, které je dobré dodržet

1. Dokumentujte

Ant přímo vybízí k vytvoření alespoň minimální dokumentace k buildu, která má pro toho, kdo si projekt stáhne a bude kompilovat, naprosto zásadní význam. Dokumentace k build skriptu se zobrazí pomocí povelu:

Buildfile: build.xml



Ukazkovy build soubor pro vytvoreni jedne casti podprojektu,

v tomto pripade klientske aplikace typu Hello World.

 

(c) 2003, Daniel Michalik pro ABC Linuxu

 

Main targets:

 

 clean     Odstrani soubory vznikle buildem.

 compile   Provede kompilaci java souboru.

 copyrsrc  Prikopiruje mezi kompilovane soubory dalsi runtime soubory.

 deploy    Zkopiruje vytvoreny produkt na webovy server.

 package   Zabali kompilovane class soubory do vysledneho baliku.

 prepare   Vytvori nezbytne adresare pro build.

 run       Vytvori a spusti produkt.

 

Default target: package

Vytvoření výše uvedené dokumentace je velmi snadné. Prvních pár řádků s obecnou informací o projektu se vytvoří ve skriptu pomocí XML značky description umístěné na počátku pod kořenovou značkou project:

V seznamu cílů se popis cíle vyskytne tehdy, obsahuje-li značka target příslušného cíle atribut description:

2. Držte se zavedených konvencí

Open source projekty používající Ant konvergovaly časem k určité formě strukturování a pojmenování cílů (targets) ve skriptech. Pokud můžete, držte se těchto osvědčených konvencí. Všichni, kdo budou váš skript spouštět, vám budou vděčni, když se bude skript chovat tak, jak jsou zvyklí.

K standardním cílům by měl patřit cíl package, který vytvoří hotový zabalený produkt obsahující veškeré knihovny, spouštěcí skripty apod. Pro testování je ideální, pokud je takto zabalený produkt bez další instalace přímo spustitelný.

Jiným často používaným cílem bude cíl deploy, který provádí instalaci produktu, ať již na aplikační server v případě J2EE aplikace nebo web server v případě JNLP klienta.

3. Izolujte nastavení výsledné konfigurace

Hlavní zásada zní: adresář src obsahující zdrojové kódy je nedotknutelný. Soubory vyžadující konkrétní nastavení (IP adresy, URL a různé další konstanty) by měly být vytvořeny ve formě šablon obsahujících proměnné, které se teprve v průběhu buildu nahradí konkrétními hodnotami.

Podobně jako zdrojové kódy by měl být nedotknutelný také build skript. Ant umožňuje nastavovat hodnoty proměnných několika způsoby. Buď je to značkou <property name="..." value="..."> nebo textovým souborem s obsahem definovaných hodnot pomocí značky <property file="..." />. Přesuňte do textových souborů právě ty hodnoty, které očekáváte, že uživatel může měnit, a okomentujte jejich význam. Používáte-li např. jiný typ kompilátoru než je obvyklé (třeba jikes), přesuňte typ kompilátoru jako parametr do externího souboru. Zkrátka, ve skriptu nemají co dělat nastavení závislá na vašem systému.

Pro konkrétní nastavení je dobré vytvořit v projektovém adresáři podadresář conf, který bude obsahovat konfigurační profily s hodnotami nastavení pro jednotlivá cílová prostředí. Jednotlivé konfigurační profily se pak přepínají pomocí jediného řádku v souboru build.properties v hlavním adresáři projektu. Podrobně si tuto techniku vysvětlíme v další části článku.

4. Izolujte podprojekty

Ačkoliv lze více podprojektů organizovat pomocí jediné hierarchie adresářů zdrojových kódů tříd a jediným sdíleným adresářem společných knihoven, nelze tento postup pro komplexnější projekty doporučit. Brzy totiž ztratíte přehled, které knihovny potřebuje ten který podprojekt a údržba build skriptu se záhy stane noční můrou.

Z dlouhodobého hlediska je výhodnější, když má každý podprojekt svůj adresář knihoven, zdrojových kódů a svůj vlastní build skript. Zkrátka, je co nejvíc izolován od zbytku projektu. Jistou nevýhodou může být skutečnost, že některé společné knihovny jsou na více místech v projektovém adresáři, ale v praxi je tato nevýhoda spíše zanedbatelná.

Pokud má každý podprojekt svůj build skript, je žádoucí vytvořit hlavní build skript, který zajistí hromadné vykonání skriptů jednotlivých podprojektů.

V ideálním případě je izolace projektu dotažena až tak daleko, že projekt obsahuje vlastní kopii Antu. Jelikož se Ant neustále vyvíjí, nenastane situace, že projekt vyžaduje jinou verzi Antu, než máte v systému.

Co příště?

V dnešní části jsme si vysvětlili zásady, které je dobré dodržovat pro robustní návrh build systému. V další části článku se podíváme na reálný příklad build skriptů, které ilustrují, jak tyto zásady použít.

Diskuse k tomuto článku

a jsem s nim moc spokojen :-)

Zakladatel tohoto portálu. Twitter, LinkedIn, blog, StackOverflow

20.11.2003 13:34 Lukáš Zapletal | skóre: 42 | blog: lzapův svět | Olomouc
Rozbalit Rozbalit vše abicko pouziva ant

Kdo nepoužívá Ant jako by nebyl... :)

Later --- Lukáš Zapletal

> Z dlouhodobého hlediska je výhodnější, když má každý > podprojekt svůj adresář knihoven, zdrojových kódů a > svůj vlastní build skript. tento postup ma vsak tiez svoje nevyhody, ktore sa prejavia hlavne pri velkom mnozstve projektov a podprojektov. 1.) pri distribucii zdrojovych kodov je potrebne distribuovat aj pouzite kniznice, co nafukne celkovu velkost zdrojoveho balika. 2.) Buildovacie scripty (build.xml) obsahuju postupy pre vykonavanie urcitych cinnosti. Ked mam viac projektov/podprojektov a chcem pridat novy, zmenit povodny ciel musim prejst vsetky build.xml a vykonat potrebne zmeny. Riesenim uvedenych problemov sa snazi byt Maven. Zavislosti na knizniciach ( ako aj vela dalsich dokumentacnych veci ) sa popisuje deklarativne v subore project.xml. V pripade potreby kniznic si ich maven stiahne do lokalnej cache z centralneho repository. Postupy ako vykonat dany ciel ( napr. kompilacia, deploy, vytvorenie dokumentacie, javadoc ... ) nie su sucastou projektu, ale su sucastou mavena. Presne povedane su realizovane cez plugin do mavena. Vytvorenych pluginov je velke mnozstvo, takze je z coho si vyberat. Dalsou vyhodou mavena je generovanie dokumentacie o projekte. Ukazkou ako taka dokumentacia vyzera su napr. domovske stranky projektu.. Polozky v casti "Overview" su udrziavane "rucne", "Project Info" je generovane na zaklade obsahu suboru project.xml, "Project reports" su rozne reporty generovane cez pluginy zo zdrojoveho kodu aplikacie. Ak si vsak myslite, ze teraz uz na ANT mozete zabudnut, nie je to celkom tak .... Maven je postaveny nad antom, pouziva jeho tasky.