Myšlenky dne otce Fura

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.

Přímočarým řešením je vytvoření nějaké info stránky se seznamem knihoven / modulů a jejich verzí, které jsou použity v aplikaci, která by vám umožnila všechny potřebné informace zjistit během vteřiny. V tu chvíli už se ale dostáváte k druhému problému - jak zajistit (nelépe automatické) verzování knihoven, aby bylo zajistěno, že se knihovny budou pravidelně verzovat, a že u všech knihoven bude tato informace jednoduše přístupná (a opět nejlépe jednotným způsobem, aby info stránka neměla s vyhledáváním této informace problém).

Problém se zdá možná jednoduchý, ale můžete narazit na celou řadu nepříjemností jako se to stalo třeba nám. Řešení může být ale opravdu velmi prosté …

(pokračování …)

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.

(pokračování …)

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

Krom tohoto problému se v článku dotknu ještě site:deploy opět na server přes SSH s použitím privátního klíče. Jeden by si myslel, že zprovoznění prvního problému vyřeší všechny problémy tohoto charakteru, ale ouvej. Řada věcí je v maven pluginech řešena znovu a jinak. A toto je přesně ten případ. Řešení tu najdete také.

(pokračová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í.
(pokračování …)

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.

(pokračování …)

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.

HTML verzi naleznete zde

PDF verzi ke stažení zde

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.

(pokračování …)

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áší?

(pokračování …)