Jeste me napada jedna potencialni nevyhoda: Pouziti MAVENu muze byt problematicke u projektu, ktere vyuzivaji specialni vlastnosti IDE. Mame napr. projekt, ktery funguje na WebSphere a vyviji se pomoci WebSphere Application Developer (WSAD). IDE generuje podpurne tridy pro webove sluzby.
Neumim si dost dobre predstavit, jak bychom toto resili MAVENem. Mozna by se dal udelat nejaky vlastni plugin. WSAD ma take svoji vlastni strukturu adresaru a modulu. mp. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michal Palička Sent: Thursday, August 23, 2007 10:21 AM To: Java Subject: RE: project management tools - build, test, code analysis, documentation Dobry den, radim se take mezi zastance MAVENu... :-) Strucne me napada asi toto: Nevyhody MAVENu: - vyzaduje urcity cas, nez si lide zvyknou na novy system sestavovani - dokumentace neni uplne dokonala (na prvni precteni clovek netusi, k cemu ten MAVEN vlastne je) - narocnejsi na pripravu infrastruktury (firemni repozitare apod.). - pro nektere specialni ukony ci produkty nemusi existovat vhodny plugin - existujici plugin nemusi vyhovovat vasim potrebam Vyhody MAVENu: - jakmile se s nim seznamite, nebudete uz chtit ANT :-) - centralni sprava zavislosti (knihoven) - snadny prechod na novejsi verzi knihovny, knihovny neni treba udrzovat v CVS - vsechny projekty maji obdobnou strukturu (lide se v nich budou lepe orientovat), skripty pro ANT jsou obcas "kazdy pes jina ves" - profily (parametrizace buildu pro ruzna prostredi) - podpora pro IDE (existuji pluginy pro IDE, je mozne vygenerovat projketove soubory z POMu). Podpora pro MAVEN postupne narusta, setkavam se s nim stale vice u ruznych OSS projektu. Je to videt i na www.mvnrepository.com. Myslim, ze znalost MAVENu se do budoucna vyplati, protoze smer, kterym jde, povazuji za spravny (prestoze samotny produkt muze mit sve mouchy). mp.
