There has been a lot of fuss around this issue and it seems there are already fixes in place. But in certain use-cases problems persist even if you apply fix mentioned in MRELEASE-812 issue or this ShredZone article. So if you experience the behaviour described in the title of this article keep on reading I may have a fix for you or at least I can help you debug the problem.
Existují situace, kdy aplikaci neinstalujete sami, ale instaluje ji třetí strana - ať už je třetí stranou myšlen technik zákazníka nebo kolega z jiného oddělení firmy. Vy posléze přijdete už k nainstalované aplikaci, u které si nikdy tak úplně stoprocentně nemůžete být jisti verzí neřkuli verzemi knihoven, které daná aplikace používá. Přesto tato znalost může být pro řešení některých problémů zásadní (např. proto, že oprava může spočívat v pouhé instalaci nové verze knihovny / modulu). Můžete se s tím setkat i v daleko prostším případě - pokud vyvíjíte nějaký produkt s velkým množstvím instalací - chvíli vám může trvat než zjistíte jakou verzi má daný zákazník, u kterého řešíte nahlášené problémy.
If you use Maven 2 and Teamcity integration server, you might want to perform releases on server. Although it's not so complicated, some things must fit one into another and you might spend a lot of time till you find out how to configure pom.xml and build configuration. For those of you, who need to setup it, this article could come quite handy.
Let's assume that you have maven release process setuped up for your localhost. If you do not, you can look at following articles, to get it running (this is the most difficult part, that I want to avoid analyzing in this post):
Před tím, než jsem mohl ozkoušet maven-release-plugin, na který jsem si stěžoval v článku Co bych rád slyšel v září na CZJUG, musel jsem rozchodit přístup do našeho CVS skrze SSH s přihlašováním pomocí privátního klíče. Po zkušenostech můžu říct, že to byla práce nelehká a musím potvrdit negativní ohlasy ostatních, že v některých případech dokumentace k Mavenu (respektive k jeho konkrétním pluginům) je opravdu nedostatečná. Oříšek jsem nakonec rozlousknul díky zdrojákům a oddebugování.
Tento post je tak trochu věnován Petru Ferschmannovi ze SoftEU, který bude mít 19. září 2007 přednášku na téma praktické nasazení Mavenu na CZJUGu. Jelikož vím, že občas na můj blog zamíří (doufám že pravidelně :-) ), věřím, že na článek zareaguje a kdo ví - třeba na moje otázky v září odpoví.
Vycházím z praktické zkušenosti (cca 3/4 roku staré tedy), kdy jsem se snažil použít maven-release-plugin pro vydávání verzi v multiprojektu. Typicky mám parent pom.xml v nadřízené složce, a pom.xml jednotlivých modulů ve složkách o úroveň níže (obdobný problém jsem ale měl i pokud jsem parent umístil také do složky druhé úrovně, myslím). Při použití maven-release-pluginu na parent projektu bych čekal, že správně releasne jak hlavní projekt, tak všechny moduly v něm registrované. Problém je v tom, že plugin všechny zdrojáky zataguje ve VCS a následně si je vycheckoutuje pod tímto tagem do složky "target". Po vycheckoutování mu ale nesedí relativní cesty k pom.xml jednotlivých modulů a celé to vyhoří. Jediným způsobem, jak plugin použít, pro mne bylo spouštět postupně releasy na všech modulech projektu, což bylo velmi nekomfortní. Dále mě na celém tomto způsobu vadilo, že v celém release procesu jsou spouštěny např. testy 2x - přitom by přeci stačilo je spustit jen jednou. Navíc parametry, se kterým se spustil daný release se posléze nepřenesly do buildování již té vycheckoutované verze - mám ten dojem, že plugin si interně spouští úplně novou instanci mavenu na zbuildování vycheckoutované verze.
Integrace build systému do IDE je věc pro mne nepostradatelná. Není ovšem integrace jako integrace. Pokud používáte Maven 2 a IntelliJ Idea jako my zjistíte, že pluginů je řada, ale velmi rozdílné kvality a velmi rozdílné aktuálnosti.
Navíc osobně si velmi cením možnosti buildovat projekt přímo z IDE - toto buildování je totiž řádově rychlejší než kterýkoli ant / maven build, jelikož IDE ví přesně, které třídy se změnily a zda je třeba překompilovat závislé třídy a když, tak jaké. Ant a Maven při vší své dokonalosti dokáží rozeznat a překompilovat jen třídy se změněným timestamp, ale závislé třídy nezkompilují. Dále mi to umožňuje jednoduše používat HOT replace funkcionalitu, pouštět testy přímo z IDE atd. Důvodů je prostě řada. Proto jsem chtěl, aby mi plugin pomohl zůstat ve svém IDE, ale pro správu dependencí a produkčních buildů využít daleko lepších možností Maven 2. Chvíli to trvalo, ale našel jsem.
Na serveru The Server Side vyšel zajímavý článek o Artifactory. Pro ty kdož chtějí Artifactory nasadit pro vnitrofiremní použití se jistě jedná o velmi užitečný článek. Faktem je, že Artifactory se dá velmi jednoduše nasadit i bez větších znalostí - jedná se o velmi user friendly aplikaci.
Jediný problém, na který jsem narazil (a který je tedy relativně dost nepříjemný) byl ve verzi 1.2.1-rc0, kdy při deployi do repository se náhodně vracel HTTP 500 - Internal Server Error, díky problematické práci se zámky v JackRabbitu. Více zde. Problém je ale v pozdějších verzích již opraven
Na http://theserverside.com vyšla upoutávka na elektronickou knihu o Mavenu. Trošku jsem do ní nakouknul a opravdu poměrně podrobně a přehledně pokrývá problematiku okolo tohoto skvělého projektového systému. Vřele doporučuji, už jsem si ji zařadil do fronty - díky přehlednosti v ní jistě bude možné nalézt i řešení na ad hoc problémy.
Kdo někdy nasazoval Maven2 pro vnitrofiremní použití, možná se setkal s aplikací Maven Proxy od Codehausu. Od vydání verze 0.2 již uběhlo přes rok a Maven Proxy neutrpěla žádnou aktualizaci, zato se však objevila nová konkurence v podobě Artifactory od JFrog. Již základní sada funkcí dostupná v Maven Proxy dostatečně obhájí náklady s jejím zavedením, Artifactory však předbíhá Maven Proxy vlastnostmi, které ocení především větší organizace. Jak sami autoři popisují, začínali sami s Maven-Proxy. Ve chvíli kdy její možnosti přestávaly stačit, začali si je dodělávat a došli do stavu, kdy jich prostě bylo tolik, že nebylo myslitelné "propašovat" je do původní Maven-Proxy.
Stále mnoho vývojářů používá pro buildování svého projektu ant nebo maven 1, někteří si možná píší dokonce své sh nebo bat skripty. Možná o nové verzi Mavenu vědí a možná mají důvody proč zůstat u svého "osvědčeného" řešení. Sám jsem mezi ně patřil, ale přešel jsem - a teď vidím, že jsem udělal dobře, móóóc dobře :).
Jaké hlavní výhody Maven 2 přináší?
Maven je především koncentrátem dobrých zkušeností z oblasti správy projektů. To není jen termín - v jeho případě je to pravda. V praxi to znamená, že jej nepoužíváte jen k sestavování instalačních balíčků, ale že pokrývá všechny oblasti, které se správou projektu souvisí a hlavně - navádí vás, jak je už od začátku dělat správně.
