Apache Ant - jak na složité projekty - II

27. 11. 2003 | Daniel Michalik

Články - Apache Ant - jak na složité projekty - II  

V minulé části jsme si řekli, jaké zásady máme dodržovat při návrhu robustního build systému pomocí nástroje Ant. V dnešní části se podíváme na praktickou ukázku.

Reálný příklad

Pro účely tohoto článku byl vytvořen ilustrační miniprojekt, kterého účelem je vytvořit dva provázané fiktivní produkty:

1. klientská aplikace - pomocí JNDI (Java Naming Directory Interface) se bude připojovat na J2EE aplikační server a pomocí JMS (Java Messaging Service) posílat do front serveru zprávy. Aplikace bude spustitelná přes Java Web Start pomocí JNLP souboru, pomocí spouštěcího příkazu z příkazové řádky a také přímo z Antu.
2. serverová aplikace - pomocí JDBC (Java Database Connectivity bude přistupovat k databázi a pomocí JNDI a JMS poskytovaných aplikačním serverem bude odpovídat klientské aplikaci. Aplikace bude spustitelná pomocí spouštěcího příkazu z příkazové řádky.

Uvedené aplikace se omezí pouze na to, že vypíší parametry připojení. Pro zjednodušení jim budeme dále zkráceně říkat klient a server.

Kompletní kompilovatelný projekt si můžete stáhnout zde. Autor jej vytvořil s přesvědčením, že může být pro vás inspirací pro vaše projekty. Pokud jej vylepšíte, bude vděčný za vaše připomínky a návrhy.

Struktura projektového adresáře

Struktura projektu je znázorněna na následujícím obrázku:

V hlavním adresáři se nacházejí tři soubory. Soubor build.xml obsahuje hlavní antovský skript, kterého jediným účelem je inkrementovat číslo buildu nacházející se v souboru build.number a spouštět Antovské skripty pro klienta a server, umístěné v příslušných podadresářích src/client a src/server.

Soubor build.properties obsahuje pouze odkaz na příslušný konfigurační profil definovaný v podadresáři conf:

# Soubor nastaveni pro build file je ulozen v prislusnem konfiguracnim # profilu. Konfiguracni profil je soubor .properties v # podadresari "conf". # # config.profile=<nazev_profilu> # config.profile=dmi #config.profile=prof2

Konfigurační profil dmi.properties používá vývojář dmi na svém počítači, který se jmenuje dmi. Kromě definice některých proměnných dále větví konfigurační profil pomocí odkazů na soubory v podadresářích jdbc a jndi. Tzn. nenastavuje zbytečně mnoho proměnných, které by se v každém profilu opakovaly, ale obsahuje přepínač na konkrétní sadu nastavení, v tomto případě typ jdbc driveru a typ aplikačního serveru.

Struktura podprojektu - klient

Adresář src obsahuje dva izolované podprojekty. Následující obrázek ukazuje strukturu podprojektu klienta:

Podadresář build obsahuje soubory vznikající během buildu, tedy zkompilované soubory a výsledný zabalený produkt (package), včetně knihoven. Adresář java obsahuje zdrojové kódy tříd projektu, lib knihovny nezbytné pro kompilaci a spuštění (skript by je měl nakopírovat do package).

Adresář rsrc obsahuje další soubory (resources), které aplikace potřebuje za běhu. Tyto soubory jsou rozděleny do dvou skupin. Soubory v adresáři etc se přibalí k výslednému jar souboru, takže jsou dostupné v classpath za běhu aplikace. Soubory v adresáři main se nakopírují do hlavního adresáře produktu - typicky se jedná o spouštěcí dávky.

Zajímavé na souborech v adresáři rsrc je, že obsahují odkazy na proměnné definované v konfiguračním profilu. Např. spouštěcí dávka run.sh je napsána velmi obecně. Zvlášť zajímavé je předání hodnot client.property1 a client.property2, které jsou pak aplikaci k dispozici pomocí volání System.getProperty("client.property1"); a System.getProperty("client.property2");:

#/bin/sh export CLASSPATH="${jar.name}" export JAVA_OPTS="-Dclient.property1=${client.property1} -Dclient.property2=${client.property2}" java $JAVA_OPTS -classpath $CLASSPATH ${main.class.name}

Výhoda substituce parametrů rsrc souborů pomocí konfiguračních profilů se stane zřejmá, když potřebujeme stejný parametr použít na více místech. Jelikož klient by měl být alternativě spustitelný také pomocí jnlp souboru, přijde vhod možnost předat klientovi stejné parametry také pomocí jnlp spouštěče:

<?xml version="1.0" encoding="UTF-8" ?> <jnlp spec="1.0"   codebase="${jnlp.codebase}"   href="${jnlp.name}"> ...   <resources>     <j2se version="1.4"/>     <jar href="${jar.name}" main="true"/>     <property name="client.property1" value="${client.property1}"/>     <property name="client.property2" value="${client.property2}"/>   </resources>   <application-desc main-class="${main.class.name}"/> </jnlp>

Teorie bylo už dost, podívejme se na výstup klientské aplikace pro jednotlivé konfigurační profily:

Profil dmi:

01 Ant Demo, build 6 02 03 Parametry JNDI pro pripojeni k JNDI serveru 04 java.naming.provider.url = jnp://localhost:1099 05 java.naming.factory.initial = org.jnp.interfaces.NamingContextFactory 06 java.naming.factory.url.pkgs = org.jboss.naming:org.jnp.interfaces 07 jndi.profile = jboss-3.0 08 09 Parametry JMS pro pripojeni k serverove fronte JMS 10 queue.name = queue/DmiQueue 11 connection.factory = RMIConnectionFactory 12 13 Dalsi parametry zavisle na konfiguracnim profilu: 14 client.property1 = dmi.value1 15 client.property2 = dmi.value2

Profil prof2:

01 Ant Demo, build 6 02 03 Parametry JNDI pro pripojeni k JNDI serveru 04 java.naming.provider.url = jnp://prof2app:1099 05 java.naming.factory.initial = org.jnp.interfaces.NamingContextFactory 06 java.naming.factory.url.pkgs = org.jboss.naming:org.jnp.interfaces 07 jndi.profile = jboss-3.2 08 09 Parametry JMS pro pripojeni k serverove fronte JMS 10 queue.name = queue/Prof2Queue 11 connection.factory = RMIConnectionFactory 12 13 Dalsi parametry zavisle na konfiguracnim profilu: 14 client.property1 = prof2.value1 15 client.property2 = prof2.value2

Ve dvou výše uvedených výstupech vidíme následující rozdíly:

• 04 - URL aplikačního serveru
• 07 - typ aplikačního serveru
• 10 - JMS fronta
• 14,15 - nastavení dvou systémových hodnot

Struktura podprojektu - server

Serverová aplikace je strukturována téměř identickým způsobem jako klient. Rozdíl je pouze ve struktuře adresáře package, který zahrnuje podadresáře lib a etc. Narozdíl od klienta není obsah adresáře rsrc/etc přibalován přímo do výsledného jar souboru, ale ponechán jako adresář, který je přidán do classpath ve spouštěcí dávce. Díky tomu lze měnit konfiguraci nainstalovaného produktu bez nutnosti rebuildu (hesla, nastavení logu apod.).

Závěr

Ant poskytuje vše, co je třeba pro robustní strukturu projektu. Klíčovým prvkem je možnost nastavovat proměnné a při kopírování provádět substituci ve zdrojových souborech. Tímto jsme však nahlédli pouze do jedné z mnoha kapitol podpory projektu, kterou Ant přináší. Pro Ant existuje celá řada užitečných tasků, ať již integrovaných nebo třetích stran - generátorů kódu (XDoclet), formáterů zdrojových kódů, kontrol kvality zdrojového kódu, podpory pro unit testing apod.

Pokud jste ještě Ant nikdy nepoužili, vyzkoušejte jej - a uvidíte, že si pak bez něj nebudete dokázat představit svůj programátorský život. Je velmi dobře zdokumentovaný, obsahuje jak úvod typu "snadno a rychle", tak solidní referenční příručku.

Diskuse k tomuto článku