Apache Ant - jak na složité projekty (diskuse)

[Leoš Literák]

a jsem s nim moc spokojen

[Lukáš Zapletal]

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

[Vladimir Kralik]

> 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.