Tutoriale Maven
Kurs Maven a [cz.04]  porzÄ…dki +
uzupełnienie
by YaQzi: Luty 18, 2014
Mamy utworzony projekt, mamy wydzielone moduły współpracujące ze sobą i korzystające z bibliotek
zewnętrznych zaciąganych automatycznie przez mavena i załączanych tam gdzie potrzeba. Przyszła więc pora na
 ogładzenie naszego projektu pod względem konfiguracji oraz dopowiedzenie kilku ważnych spraw, m.in. co to
jest tak właściwie to mvn clean install?
Parametry (properties)
Gdy zachodzi potrzeba zaktualizowania wersji jakiejś biblioteki w całym projekcie strach zagląda w oczy i dzieją
się dziwne rzeczy ponieważ nie zmieniliśmy jej we wszystkich występujących miejscach wskutek czego do paczki
wynikowej trafiły dwie wersje tej samej biblioteki. W najlepszym razie serwer aplikacji od razu potraktuje nas np.
dziwnym ClassCastException po czym w miarę łatwo domyślimy się o co chodzi. W najgorszym wypadku owa
nadmiarowość da o sobie znać w jakiejś bardzo specyficznej sytuacji po dłuższym czasie, kiedy nikt już nie będzie
brał pod uwagę błędu związanego z podnoszeniem wersji. Co zrobić w takiej sytuacji? Siadać, płakać i rwać włosy
z głowy. Dlatego też zgodnie ze starą zasadą  lepiej zapobiegać niż leczyć w naszej aplikacji ustrzeżemy się
od tego typu problemów i odpowiednio uporządkujemy zależności.
Generalne założenie jest takie, że wszystkie wersje używanych zależności definiujemy w tagu i w
samych zależnościach posługujemy się już parametrami. Np dla kino-dao będzie to wyglądało tak:
Jak widzimy w obrębie properties możemy tworzyć nowe tagi, które stają się naszymi parametrami w dalszej
części pliku pom i możemy się do nich odwoływać poprzez ${nazwa.parametru}. To bardzo pomocne gdy
załączamy kilka modułów tej samej wersji całości (np Spring) oraz gdy zależności idą w dziesiątki. Nie musimy
przekopywać się przez cały plik, tylko widzimy użyte wersje od razu. Można też wszystkie propertiesy trzymać w
głównym pomie, ale zostaną one poprawnie zinterpretowane w pomach zależnych dopiero po jawnym wskazaniu
w nich rodzica.
ś ż ę
Profile
Obecnie budujemy wszystkie moduły jednocześnie. Załóżmy, że nasz projekt jest już na tyle duży, że jego
budowanie zajmuje kilkanaście minut. Zespoły podzielone są na część odpowiadającą za kino-client oraz
kino-worker. Po co ktoś pracujący nad modułem client ma tracić czas na budowanie projektu worker skoro
nie jest on mu do niczego potrzebny? Jedynym celem może być walidacja takiego projektu pod względem zmian
wprowadzanych we współdzielonych modułach ale załóżmy że nie chcemy tego robić. Można albo lokalnie
zmodyfikować sobie plik pom, co jest uciążliwe i niewskazane, albo utworzyć profil. Profil to obszar, który
zostanie wywołany tylko w przypadku jego wywołania po unikalnym id. Założymy dwa profile do budowania
aplikacji client oraz worker. Trzeci profil budujący wszystko będzie aktywny domyślnie tj. w sytuacji nie
podania żadnego profilu:
Konkretny profil uruchamiamy poprzez podanie parametru -P:
Jak widać powyżej profil worker pominął w budowaniu moduł client, dokładnie tak jak chcieliśmy.
Cykl życia
Do tej pory korzystaliśmy ciągle z polecenia install, nie wiedząc tak naprawdę dlaczego. Podczas budowania nie
wiadomo skąd pojawiały się tam również jakieś testy. Za wszystko odpowiada tzw cykl życia czyli szereg celów
(goals) następujących po sobie. Są to etapy budowania aplikacji od kompilacji, testów aż po instalację na
serwerze. Dostępne cele to:
validate  proste sprawdzenie poprawności konstrukcji projektu i niezbędnych informacji do jego
budowy,
compile  kompilacja kodów z
ródłowych,
test  wykonywanie testów jednostkowych,
package  budowanie paczki dystrybucyjnej,
integration-test  testy integracyjne w środowisku testowym,
verify  sprawdzenie poprawności paczki,
© Emil KaczyÅ„ski - wszelkie treÅ›ci zawarte na te stronie objÄ™te sÄ…ClicencjÄ… VE COMMONS
REATI
install  instalacja paczki w repozytorium lokalnym,
deploy  umieszczenie paczki na serwerze lub repozytorium zdalnym,
Dlaczego używaliśmy install? Ponieważ chcieliśmy mieć możliwość integracji modułów i uzależniania ich od
siebie. Mimo, że cały czas mieliśmy je w tym samym folderze to zależności wiązały je na podstawie naszego
lokalnego repozytorium. Gdybyśmy teraz dodali nową encję i wykonali na projekcie cel (goal) package nie
byłaby ona widoczna w zależnych modułąch! Dlatego najczęściej korzysta się z polecenia clean install, chyba że
projekt ma już spore rozmiary i całościowe przebudowywanie go jest uciążliwe.
Pluginy
Czysty maven nie jest zbyt duży, ale jego potencjał drzemie w bardzo łatwej rozszerzalności jego funkcjonalności
za pomocą dodatkowych pluginów. Z kilku już nawet korzystaliśmy bo do ich użycia jedyne co potrzeba to
repozytorium zdalne, w którym maven odnajdzie potrzebny plugin. Jeśli zajrzymy do pliku pom aplikacji
client lub worker znajdziemy tam np skonfigurowany maven-compiler-plugin, maven-
war-plugin, maven-dependency-plugin. Mało tego. Wpisując mvn eclipse:eclipse również
skorzystaliśmy z pluginu eclipse wywołując na nim goal  eclipse . Więc jak widać samo skorzystanie z
dodatkowej wtyczki jest banalne i nie wymaga dodatkowych wyjaśnień, a pluginów jest naprawdę mnóstwo, np
do automatycznego wersjonowania bazy danych, do doklejania gdzieÅ› w stopce projektu numeru rewizji z
repozytorium, minifikacji kodu javascript i wiele wiele innych&
Dodatkowe repozytoria zdalne
Pamiętasz ile było szablonów projektów dostępnych przy tworzeniu projektu z archetypu? Wydawało się, że
całkiem sporo, ale tak naprawdę to tylko najważniejsze i najpopularniejsze z nich. Archetypy, pluginy, możliwe
dependency do wykorzystania zależą od zdefiniowanych repozytoriów zdalnych mavena, czyli czegoś takiego co
maven składuje u Ciebie na dysku w folderze .m2, z tym że z dostępem online. Dodatkowe repozytoria można
definiować na kilka sposobów. Globalnie w pliku \conf\settings.xml mavena, tag , oraz lokalnie
dla danego projektu, modułu poprzez tag :
Często korzysta się również z repozytorium mavena w obrębie firmy, np Sonatype Nexus, gdzie przechowuje się
artefakty projektów wewnętrznych.
Podsumowanie
Potrafisz utworzyć i uporządkować projekt oparty o mavena. Potrafisz dodać do niego profile i wiesz na czym
polega proces budowania przez niego aplikacji. Jak na podstawowe wykorzystanie mavena wiesz już całkiem
sporo, ale zachęcam do samodzielnego eksperymentowania (no, co się stanie gdy zaczniemy tworzenie projektu
© Emil KaczyÅ„ski - wszelkie treÅ›ci zawarte na te stronie objÄ™te sÄ…ClicencjÄ… VE COMMONS
REATI
narzędzie/program tym możesz być bardziej leniwym bo praca będzie wykonywała się sama.
A ponieważ głowa nie śmietnik, warto mieć pod ręką tą małą ściągawkę: LINK.
LetItRock pisze:
MARZEC 8, 2014 O 21:47
bardzo lekko czytany jest tutorial, najlepszy kurs =) dzięki wielkie =)
ODPOWIEDZ
Emil Kaczyński pisze:
MARZEC 12, 2014 O 22:39
dzięki również
ODPOWIEDZ
Yuppy pisze:
MARZEC 27, 2014 O 15:55
Kurs dobry, ale nie ustrzegł się kilku drobnych błędów
Definiowanie wersji zależności jako propertiesy jest dobre, ale jeszcze lepiej sprawdza się mavena sekcja
dependencyManagement. Wtedy wersje zależności określamy jedynie w głównym pliku pom, a w modułach
podrzędnych w ogóle nie dodajemy elementu version przy zależnościach.
Kolejna sprawa, to widzę że nadużywasz zbytnio polecenia mvn clean install.
Przede wszystkim  clean jest rzadko potrzebny (jedynie wtedy, gdy robimy jakieÅ› inwazyjne zmiany, np. w
zależnościach), warto więc go pomijać, tym bardziej że znacznie skraca czas budowy projektu. Przy małych projektach
nie ma to większego znaczenia, przy większych ma i to duże.  clean czasami sprawia też małe problemy dla pluginu
m2eclipse, jeśli używamy wsparcia mavenowego w IDE, wtedy przebudowanie projektu trwa jeszcze dłużej.
Faza  install również jest sporo nadmiarowa. W większości przypadków należy używać fazy  package lub  verify  ta
druga, jeśli chcemy wywołać dodatkowo testy integracyjne (trzeba mieć na uwadze, że te również mogą wykonywać się
dość długo, jeśli mamy ich sporo). Jeśli komendy wywołujemy z głównego folderu projektu (lokalizacji głównego pliku
pom), nie musimy się martwić o brak zależności w repozytorium lokalnym. Te są potrzebne jedynie wtedy, gdy
wywołujemy polecenie w katalogu modułu podrzędnego, który  nie widzi modułu w hierarchii obok  wtedy najpierw
musimy zainstalować brakujące moduły.
Podsumowując przeważnie wystarcza zwykłe  mvn package .
ODPOWIEDZ
© Emil KaczyÅ„ski - wszelkie treÅ›ci zawarte na te stronie objÄ™te sÄ…ClicencjÄ… VE COMMONS
REATI
Emil Kaczyński pisze:
MARZEC 27, 2014 O 16:36
Dzięki wielkie Yuppy! Jak tylko wykrzesam trochę czasu to zaktualizuję info i tutaj i w poprzedniej
części, aczkolwiek muszę poeksperymentować z  package bo nie jestem przekonany czy skoro paczka nie
jest wtedy instalowana w lokalnym repo to moduły, które z niej korzystają na pewno dostaną nową wersję,
z nie tą z repo właśnie?
ODPOWIEDZ
Yuppy pisze:
MARZEC 28, 2014 O 10:32
Jeśli uruchamiasz  mvn package w głównym folderze projektu i wszystkie moduły
podrzędne są razem odpalane, to jak najbardziej widzą siebie wzajemnie w aktualnej wersji.
Ja od jakiegoś czasu stosuję taktykę całkowitego zakazu używania fazy  install Wtedy
łatwo wyłapać niepoprawną konfigurację zależności projektu, bo nie ma ryzyka że zostanie
wzięta jakaś starsza wersja modułu z lokalnego repo, tylko poleci błąd.  install robię tylko
przy okazji robienia release przez fazÄ™  deploy .
ODPOWIEDZ
© Emil KaczyÅ„ski - wszelkie treÅ›ci zawarte na te stronie objÄ™te sÄ…ClicencjÄ… VE COMMONS
REATI