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.

6 komentářů u „Proč Maven“

  1. Petre, pekny clanek, ale v posledni dobe jsem zaznamenal par ohlasu vyvojaru, kteri na Maven diky jeho magicnosti pekne nadavali… Nechtel by jsi v zimnim CZJUGu vystoupit s prakticky orientovanou prednaskou o Mavenu?

  2. No tak plugin pro automaticke spousteni Jetty uz existuje i pro Anta. Navic prikaz java -jar start.jar muzete spustit celkem bez potizi i z Anta.

    Navic chcete-li spustit tohoto jettyho s parametry pro debug tak aby naslouchal na urcitem soketu, tak bohuzel nemate jinou moznost nez s temito parametry spoustet komplet cely Maven. Pak ale pripojeni naslouchace ceka cely maven a ne pouze Jetty server, takze treba i kompilace a vsechno kolem toho.

    Co se tyce XML nasazovace, tak i kdyz se tvrdi ze je pro Ant slozitejsi a delsi, ja mam pocit presne opacny. Zakladni paramtery soupnete do property souboru a vetsinou a cely skript uz pak je vetsinou porad stejny. Kdezto u Mavenu musite prachazet spoustou Depnedecies, jinak vam bude projekt sebou tahat strasnou spostu nepotrebnych knihoven.

    Jinak samozrejme ja jsem taky presel z Anta na Mavena, proste clovek kdyz prejde na Mavena musi pocitat s tim, ze se bude muste naucit psat pluginy, protoze nektere problemy bez toho nevyresi, treba zminovany testovaci rezim v Mavenovi.

    Btw. ten HotSwap samozrejme bezi i v Emacsu s JDEE a je jedno jestli pouzijete ant, maven nebo make 🙂

  3. Ad výhoda „Velké soubory v repository“… A jak řešíš reprodukovatelnost buildu? Jaký je proces čistého buildu, když řekněme
    – máš vlastní knihovny (je třeba je instalovat do maven repository);
    – nemůžeš se spolehnout na repo1, protože přeci jen vyvíjíš komerční produkt;

    Problém je v tom, že když budu mít suchej ant skript a knihovny v SVN, vim, že kdykoli udělam checkout, všechno bude souhlasit a příští build bude stejný jako ten před rokem. Zatímco s Mavenem, udělam checkout pomů a build dopadne podle toho, jestli běží repo1, jestli náhodou někdo nesmazal tu knihovnu, podle verze mavenu (různé řešení tranzitivních závislostí). Takže se mi může stát, že dostanu něco jiného nebo vůbec nic.

    Co Ty na to :-)?

  4. Ahoj,
    zajimalo by me jestli jeste nekdo pouziva Maven1. Ja jsem se pokousel migrovat nas projekt z M1 na M2 a docela jsem pohorel.

    Zakladni buildovani je v pohode, ale build na vytvoreni celeho produktu je uz slozitejsi.
    Musim se priznat, ze M1 mi prijde jako neco mezi Antem a M2 a zacina mi to docela vyhovovat. Problem s M1 je ve chvili, kdy se neco meni. S M2 jsem pracoval skoro rok, protoze jsem nepotreboval vytvaret build celeho produktu a to ze nepisi co mam delat, ale jak se mi moc libilo, akorat mi cely M2 prijde strasne tezkopadny a podrizovat cely buildovaci system podle toho jak to jde v M2 se mi moc nechce.

  5. Zdravím,

    používal jsem kdysi Maven 1, ale pak jsme přešli na Maven 2 a už bych se nevracel. Pokud máte sestavování projektu složitější (např. toho hodně generujete), zkuste použít antrun.

    Ona ta nutnost přizpůsobit projekt Mavenu 2 je nakonec jedna z nejlepších vlastností. Projekt se tím pádem celkem zjednodušil a dobře fungují doplňkové nástroje (Hudson, různé reporty, release-plugin, …).

    Takže spíš napište, co konkrétního vám nejde a zkusím Vám poradit .Ale určitě už bych se k Maven 1 nevracel. Minimálně je udržovaná jen pro lidi, kteří nemohou přejít na Maven 2.

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *