Najprościej mówiąc – maven to takie narzędzie, które potrafi automatycznie kompilować kod Javy i składać go w potrzebne nam paczki .jar, .war, .ear itd. Co ważne – potrafi to też robić gdy projekt jest podzielony na wiele zależnych od siebie modułów.

Załóżmy, że mamy projekt KINO, którego wynikiem są dwie aplikacje webowe: CLIENT oraz WORKER. Obie korzystają z tej samej bazy danych, tych samych encji i serwisów. Różnią się jedynie samą częścią webową. Możemy więc przykładowo wyodrębnić następujące moduły:

  • KINO-Entities – czyli model bazy danych zmapowany na klasy Javy,
  • KINO-DAO – część odpowiadająca za operacje na bazie danych,
  • KINO-Services – zawierający wszystkie funkcjonalności i operacje,
  • KINO-CLIENT – apliwacja webowa dla klientów,
  • KINO-WORKER – aplikacja webowa dla obsługi kina.

Oczywiście jest to podział przykładowy ustalany zazwyczaj przez architekta projektu.
Łatwo zauważyć, że zależności pomiędzy tymi modułami wyglądają tak:

przykład

Dlaczego tak? Ponieważ obie aplikacje będą korzystały z podobnych funkcjonalności udostępnianych przez Services (np podaj zajętość sali). Services potrzebuje z kolei modułu DAO aby pobrać potrzebne dane z bazy a wszystkie moduły operują na modelu encji, dlatego powinien on być widoczny w każdym z nich.
Przełoży się to na następujące paczki w javie:

  • pl.ekaczynski.kino.entities
  • pl.ekaczynski.kino.dao
  • pl.ekaczynski.kino.services
  • pl.ekaczynski.kino.cliet
  • pl.ekaczynski.kino.worker

No i co teraz?
Zakładamy jeden projekt w Eclipsie? Jak zatem zbudujemy w nim dwie aplikacje? Opornie, a poza tym po co np w aplikacji CLIENT część z aplikacji WORKER? Słabo…
Zakładamy więc dwa projekty? CLIENT i WORKER? Ok, ale zaraz zaraz… Obydwa korzystają z tych samych klas encji, serwisów i dao… Skoro tak, to powinniśmy je skopiować i aktualizować na bieżąco w obydwu aplikacjach. A co jeśli będzie więcej niż dwie aplikacje końcowe? Też słabo…

Co zatem zrobić? Ano skorzystać z pomocy mavena i podzielić projekt na pokazane powyżej moduły mavenowe. Co nam to da? Przede wszystkim pełną kontrolę nad zależnościami (ang. dependencies) pomiędzy poszczególnymi modułami. Maven potrafi dla każdego takiego modułu wygenerować plik .jar, który następnie załączy do innych modułów. Oczywiście jeden moduł może być współdzielony przez wiele innych. Za pomocą wbudowanych pluginów można również prosto zbudować pliki .war, .ear itp. gotowe do uruchomienia na serwerze.

Mamy więc załatwioną kwestię wielu aplikacji bez duplikowania współdzielonych przez nie klas. Prawda, że fajnie? A co gdyby aplikacja wynikowa była tylko jedna? To już zależy od tego jak duża by ona była i jakie są preferencje zespołu, ale generalnie podział chociaż na podstawowe moduły powyżej sprawia, że projekt jest bardziej czytelny i łatwiejszy w utrzymaniu a sam maven na pewno przyda się także w innych aspektach projektu.


Kurs Maven’a [cz.01] – wstęp
Kurs Maven’a [cz.02] – od czego zacząć
> Kurs Maven’a [cz.03] – do czego ten maven
Kurs Maven’a [cz.04] – zależności
Kurs Maven’a [cz.05] – instalacja
Kurs Maven’a [cz.06] – tworzenie modułu, archetyp
Kurs Maven’a [cz.07] – tworzenie modułu, kopiowanie
Kurs Maven’a [cz.08] – tworzenie modułu ręcznie
Kurs Maven’a [cz.09] – parent pom
Kurs Maven’a [cz.10] – import do Eclipsa
Kurs Maven’a [cz.11] – zależności zewnętrzne
Kurs Maven’a [cz.12] – zależności wewnętrzne
Kurs Maven’a [cz.13] – scope, exclusion
Kurs Maven’a [cz.14] – parametry (properties)
Kurs Maven’a [cz.15] – profile
Kurs Maven’a [cz.16] – cykl życia
Kurs Maven’a [cz.17] – pluginy
Kurs Maven’a [cz.18] – repozytoria zdalne
Kurs Maven’a [cz.19] – podsumowanie