Proč Maven

Chtěl bych vám přiblížit své zkušenosti s Mavenem. Kdy si myslím, že je dobré jej používat, proč je to dobré, a kdy naopak není.

Nebudu popisovat, co Maven umí a neumí. K tomu vám doporučuji záznam své přednášky Maven: praktický průvodce a bezplatnou knihu Better builds with Maven.

Jaký je hlavní rozdíl mezi Antem a Mavenem

Maven používá deklarativní definici projektu, kdežto Ant a make používají systém pravidel a jejich závislostí. To znamená, že v Mavenu řeknete:

„Chci vytvářet JAR a zde jsou zdrojové texty“

ale v Antu:

„Vezmi překladač, zkompiluj tyto zdrojové soubory a výsledek zabal jako JAR.“

U takto jednoduchého popisu překladu ještě není vidět velký rozdíl. Pokud ovšem přidáme testy, statickou analýzu textů a pokrytí testy, popis bude vypadat takto:

„Chci vytvářet JAR, zde jsou zdrojové texty programu, zde jsou zdrojové texty testů, chci pustit PMD a provést měření pokrytí testy.“

V Antu již musíte napsat:

„Vezmi překladač, zkompiluj tyto zdrojové soubory a výsledek zabal jako JAR. Nyní v tomto JARu najdi nástroj PMD a spusť analýzu nad těmito soubory. Pak v tomto JARu najdi nástroj Cobertura, tyto class soubory instrumentuj do tohoto adresáře, spusť testy, ale použij instrumentované soubory.“

Základní rozdíl je tedy v tom, že Antu říkáte jak se to má dělat, Mavenu co má dělat.

Kdysi jsem pro jeden projekt dal dohromady sadu Ant skriptů, které dokázaly projekt sestavit, dokázaly pustit testy, dokázaly zjistit pokrytí testy a některé další statistiky. Pak ovšem přišel další projekt a já chtěl tyto skripty znovu použít. Když jsem se je pokusil upravit, aby byly použitelné pro oba projekty, práce se docela zkomplikovalo. Pak se vám může stát, že pracujete na projektu na kterém máte strávit týden práce a pokud chcete využívat infrastrukturu tak, jak jste zvyklí ze svého většího projektu, strávíte několik hodinou jen její přípravou.

Ant poskytuje větší kontrolu nad tím co se kdy děje, ale je to pracné. Assembler vám také dává jasnou kontrolu nad tím co se kdy děje, ale přesto jej nepoužíváte.
Myslím, že hlavní záchranou Antu dnes je jeho skvělá integrace a generování v IDE.

U Antu jsem narazil na následující problémy/pracnost:

• Rozchodit další reporty. – Vždy když jsem chtěl přidat další nástroj (např. JXR nebo JavaDoc), je to vždy celkem pracné.
• Generování výsledků automatických testů a analýz.
• Synchronizace projektů v IDE a v Antu. – Změníte-li verzi knihovny nebo přidáte další, musíte vždy aktualizovat projekt. Pokud na projektu pracuje více lidí, může to způsobovat nepříjemné problémy při opomenutí.
• Velké soubory v repository. – Aby se předešlo problémům s knihovnami, jsou vždy uložené i v repository. Zde zabírají více místa, zpomalují checkout, na disku jsou uloženy mnohokrát stejné knihovny, a pokud knihovna A potřebuje knihovnu B, a ta potřebuje knihovnu C, po čase obvykle nevíte k čemu knihovna C je.

Výhody a nevýhody

Z uvedených důvodů jsme se rozhodli přejít na Maven. Zde jsou některé výhody, které to přineslo:

• Správa závislostí a jejich stahování. – Pokud je projekt podporován pomocí Mavenu, je velmi jednoduché jej přidat do projektu. Jednoduše jej najdete na mvnrepository.com a zkopírujete nabídnutou část do svého pom.xml. Z repository Mavenu tahám soubory i v případě použití Antu.
• Podpora Jetty. – Webové aplikace je možné snadno spouštět přímo z Mavenu bez instalace servlet kontejneru.
• Generované stránky projektu. – Pomocí příkazu mvn site můžete vygenerovat stránku, ve které jsou všechny reporty včetně jejich vzájemného prolinkování.
• Doporučená struktura projektu. – Maven doporučuje strukturu projektu a definuje standardní fáze sestavování projektu. Díky tomuto doporučení je struktura projektů velmi podobná a lze se v nich snadno vyznat. Pokud znáte projekt appfuse.org a viděli jste vygenerovaný projekt v předchozí verzi a nyní, když používají Maven, budete vědět o čem mluvím.
• Snadné generování reportů. – Je opravdu snadné přidat kontrolu pokrytí testy, statické analýzy, JXR, JavaDoc, …
• Podpora verzovacích systémů a vydávání verzí. – Maven umí vytvořit větev (branch) v–repository, nastavit číslo verze projektu a výsledek nahrát do vaší firemní repository. K tomuto jsem byl nejdříve poněkud skeptický, ale vyzkoušel jsem si jeho použití na OpenSource projektu URL Rewriter a musím říct, že jsem si tuto vlastnost oblíbil. Opět platí, že tuto vlastnost můžete získat i s Antem, ale s Mavenem použijete standardizovaný způsob stejný pro všechny projekty.
• Můžete volat Antovské skripty. – I z Mavenu můžete volat Antovské skripty a udělat tak to, pro co neexistuje plugin a nechce se vám jej psát (přestože je to celkem snadné). Protože Ant a Maven mají trochu jiné cíle není toto řešení proti „duchu“ řešení.
• Nezávislost na IDE. – Maven má výbornou integraci s IDE. Odpadá synchronizace classpath v projektu (např. při debug režimu), je možné pouštět projekty i bez IDE (pokud použijete jen Eclipse bez Antu) a v případě Eclipse je někdy možné překládat a pouštět aplikaci přímo z IDE i bez pouštění Mavenu (takže funguje HotSwap). Jediná odpovídající alternativa je NetBeans s Antem.
• Různé nástroje. – Pro Maven existuje mnoho pluginů, které lze snadno integrovat (např. AndroMDA).
• Možnost kostry projektu a společného základu. – Pomocí Mavenu si můžete vytvořit vlastní kostru projektu (např. pro vaši firmu) a je možné mít společnou kostru pro všechny projekty např. s doporučenými reporty.
• Podpora continuum, – Continuum má dobrou podporu Mavenu.

Ale také narazíte na tyto záludnosti:

• Tranzitivní závislosti. – Závislosti vás ovšem můžou někdy i potrápit. V projektu se vám objeví nový JAR se kterým to nefunguje. Pro zjištění kdo jej do projektu „zatáhl“ použijte opět mvn site a stránku závislosti. Pak lze snadno u dané knihovny závislost vypnout (exclude). Problém je, že některé knihovny nejsou povinné (jsou optional) a to celé závislosti komplikuje. Bohužel Maven zatím nemá podporu profilů závislostí (např. chci Seam s JSF a Facelets) – příští verze by je mít snad už měla.
• Kopírování artefaktů do lokální cache. – Toto je změna přístupu, která mi trvala nejdéle. Dříve jsem v každém projektu měl adresář build/ kam byly umístěny JARy podprojektů. Maven ovšem vyžaduje jejich instalaci do lokální cache (~/.m2/repository/). Pokud tedy použijete jen mvn compile knihovny nejsou do lokální cache zkopírované, a proto je nemohou použít ostatní části projektu. Musíte tedy použít mvn install.
• Větší „magičnost“. – Zpočátku se vám může zdát Maven magický. A to alespoň do doby, než jej celý pochopíte. Naštěstí za poslední rok se dokumentace Mavenu výrazně zlepšila.
• Spouštění podprogramů. – Toto je na jedné straně výhoda, ale i nevýhoda. Protože je dobře synchronizovaný projekt v IDE, lze vše snadno pouštět z něj. V projektu jsme ovšem používali mnoho jednoduchých podprogramů (s funkcí main), které něco prováděli. Ty jsme museli buď přímo přepsat na plugin, a nebo si vytvořit plugin pro jejich spouštění (mvn run:java -Dproj=import-templates).

Závěr

Maven je vhodné použít pro větší projekty s mnoha reporty, nástroji a kontinuálním buildováním. Vnucuje projektu určitou strukturu, kterou je nutné (doporučené) dodržovat. Znamená to určitou změnu návyků. Výhodou je větší jednotnost projektů, a proto také snadné přidávání dalších pluginů.

Pokud vám ovšem stačí to, co nabízí vaše IDE a nepotřebujete další vlastnosti, je obvykle jednodušší zůstat u projektů v IDE.

Největší přínos Maven přináší středně malým a středním projektům. Velkého projekty vyžadují celého člověka jen pro úpravy build systémů a u velmi malého zase složitější infrastruktura nebývá potřeba.