Celem tego rozdziału jest stworzenie pierwszego projektu Maven, skonfigurowanie budowy tego projektu oraz uruchomienie tej budowy
tak abyśmy na końcu otrzymali gotową do użycia paczkę.
Appa Notka.
Jeśli nie masz jeszcze zainstalowanego Mavena, zalecamy rozpoczęcie nauki od rozdziału Maven - Instalacja, aby móc kontynuować z pozostałymi materiałami.
Spis treści (kliknij, aby przejść):
Stworzenie projektu w Eclipse
Eclipse to wciąż jedno z najpopularniejszych IDE do programowania w Javie. Stwórzmy projekt typu Maven używając tego
narzędzia. W tym celu wykonamy trzy kroki:
1 - Otwieramy popup w Package Explorer i wybieramy opcje: New > Maven Project
2 - Dla ułatwienia zaznaczamy opcję "Create a simple project (skip archetype selection)"
3 - Definiujemy pola podobnie jak na zdjęciu. Pola te znajdą się w wygenerowanym pliku
pom.xml w projekcie.
Na koniec klikamy w przycisk Finish i czekamy aż Eclipse stworzy projekt. Struktura projektu będzie zbliżona do tej, którą
opisujemy w kolejnym punkcie.
Uwaga
Dokładne wyjaśnienie znaczenia pól z kroku nr 3 znajduje się niżej - w paragrafie "Typowy plik pom.xml".
Stworzenie projektu w IntelliJ
Stwórzmy teraz projekt typu Maven używając do tego IDE IntelliJ. W tym celu wykonamy następujące kroki:
Struktura projektu Maven
Przyjrzyjmy się teraz podstawowym cechom projektu typu Maven:
- Konfiguracja projektu przetrzymywana jest głównym katalogu projektu w pliku xml o nazwie pom.xml.
- Źródła (pliki *.java) są przechowywane w projekcie w ścieżce: src/main/java.
- Pliki statyczne (na przykład *.html, *.properties) są przechowywane w projekcie w ścieżce: src/main/resources.
Zwyczajowo tutaj przechowujemy źródła aplikacji, takie jak widoki w plikach *.html, pliki Javascript *.js (np. pliki AngularJS),
konfiguracje w postaci plików *.properties, *.yaml, *.xml itp.
- Testy (pliki Java z testami) są przechowywane w projekcie w ścieżce: src/test/java.
- Pliki statyczne testów (na przykład pliki konfiguracyjne *.properties, *.yaml, *.xml itp) są przechowywane w projekcie w ścieżce: src/test/resources.
- Jeśli używamy innych języków w projekcie to przechowujemy je analogicznie w ścieżkach: src/main/groovy, src/test/groovy.
- Po kompilacji wynikowe pliki klas (pliki *.class) są umieszczane w katalogu target .
- Zawartość katalogu target jest pakowana do archiwów (paczek) typu *.jar, *.war, *.ear itp.,
które są gotowe do wdrożenia na serwerze.
Tyle teorii. Tak to wygląda w praktyce:
Typowy plik pom.xml
Mamy więc stworzony projekt. Zobaczmy teraz co zawiera się w pliku konfiguracyjnym
pom.xml:
- Deklaracja przestrzeni nazw xml, w ramach której będziemy korzystać z tagów w pliku:
- Informacje o projekcie, w tym między innymi nazwa artefaktu oraz numer jego wersji (szczegóły w tabelce pod listingiem):
- dependencies - zależności do innych artefaktów Mavena (najczęściej innych projektów w postaci paczek *.jar) lub bibliotek zewnętrznych:
- build - sekcja dodatkowych opcji uruchamianych podczas procesu budowy projektu (możemy tutaj na przykład dodać i skonfigurować wtyczki)
- repositories - sekcja, w której możemy podać repozytoria zewnętrzne, na których Maven będzie szukał zewnętrznych artefaktów, z których korzysta projekt.
Jest ona dosyć często pomijana, ze względu na to, że repozytoria częściej definiujemy globalnie dla wielu projektów poprzez plik z ustawieniami zewnętrznymi settings.xml.
A tak to wygląda w całości:
W sekcji
build użyliśmy bardzo często używanej wtyczki (pluginu), której zadaniem jest wykonanie kompilacji zgodnie z podaną konfiguracją.
Uruchomienie za pomocą komendy mvn
Maven posiada klika predefiniowanych faz (phase), które mogą wykonać różne operacje na naszym projekcie. Uruchamiamy je tak:
Najpopularniejszymi fazami są:
- compile - kompiluje kod źródłowy oraz kopiuje zasoby do katalogu classes (w target)
- package - tworzy paczkę typu *.jar, *.war itp. (w zależności od konfiguracji w pom.xml - domyślnie jest to *.jar)
- install - instaluje wynikową paczkę w lokalnym repozytorium
- clean - czyści katalog target wraz z wszystkim wygenerowanymi zasobami
- deploy - instaluje paczkę w zewnętrznym repozytorium (poza naszą maszyną, na przykład w firmowym repozytorium)
Najczęściej używamy faz
clean oraz
install. Aby zbudować projekt wchodzimy do katalogu, w którym znajduje się
pom.xml i odpalamy komendę
mvn podając te dwie fazy:
W rezultacie powinniśmy zobaczyć coś takiego jak na poniższym zdjęciu:
W ten sposób udało się nam zrealizować plan stworzenia pierwszego artefaktu o nazwie:
appaadmin-1.0.0.jar!
Artefakt w postaci pliku
jar jest dostępny w katalogu
target, a także jest zainstalowany
w naszym lokalnym repozytorium.
Jego nazwa powstała ze złączenia
artifactId, myślnika oraz
version zdefiniowanych w pliku
pom.xml.
Lokalne repozytorium Mavena
W rozdziale
Maven - Instalacja wspomnieliśmy,
że artefakty zbudowane za pomocą celu
install są od razu instalowane w lokalnym repozytorium
.m2\repository
w katalogu domowym użytkownika. Teraz powiemy sobie nieco więcej.
Katalog
.m2\repository przechowuje artefakty w specjalnej strukturze zbudowanej
na podstawie
groupId zarówno naszych projektów, jak i tych dociągniętych ze zdalnych repozytoriów (np. z intenetu albo sieci wewnętrznej).
Tak więc, jeśli
groupId naszego projektu
spring-boot-materialy-praktyczne zdefiniowane jest jako
com.javappa,
to taką też zastaniemy strukturę katalogów. Dalej mamy nazwę artefaktu (
spring-boot-materialy-praktyczne) oraz numer wersji (
0.0.1-SNAPSHOT):
Warto tu zwrócić uwagę na datę i czas stworzenia artefaktu. Przed wykonaniem komendy
mvn clean install
wyglądało to tak:
Natomiast po jej wykonaniu czas uległ zmianie:
Przypominamy, że do zainstalowania artefaktu w repozytorium wystarczy uruchomienie komendy
mvn install.
Cel
clean jedynie czyści przed buildem katalog
target w projekcie.
Brak pliku pom.xml
Builda odpalamy w katalogu, gdzie trzymamy
pom.xml. W przypadku, gdy uruchomimy komendę
mavenową w katalogu bez tego pliku, otrzymamy poniższy komunikat. Warto więc zwracać uwagę na to, w jakim katalogu się
znajdujemy w trakcie odpalania tej komendy.
Problem z wersją Javy
Może się zdarzyć, że wersja Javy, której używamy, nie jest zgodna z wersją wpisaną w
pom.xml.
Na przykład, jeśli korzystamy aktualnie z Javy 8, a w
pom.xml mamy wpisaną wersję 11:
wtedy podczas builda dostaniemy błąd podobny do tego:
Spowodowane jest to tym, że próbujemy budować projekt Javą niższą niż ta określona w
pom.xml.
W takiej sytuacji albo zmieniamy wersję w
pom.xml, albo instalujemy nowszą wersję Javy, tak aby obie były zgodne.
Natomiast, jeśli mamy na komputerze kilka wersji Javy, możemy ustawić wersję, której tylko Maven ma używać.
Możemy to ustawić w pliku
mvn.bat albo
mvn.cmd (w zależności od wersji) w katalogu
bin Mavena
- apache-maven-x.x.x\bin:
Problem z celem clean
Kolejny często spotykany problem dotyczy celu
clean. Chodzi o to, że podczas
usuwania katalogu
target, może pojawić się problem, jeśli ten katalog lub pliki w nim
zawarte, są wykorzystywane przez jakiś proces. Na przykład może być tak, że w jednej z konsol
cmd
sami "przebywamy" właśnie w tym katalogu. W takiej i podobnych sytuacjach otrzymamy taki błąd:
Czasem okazuje się, że sprawdziliśmy wszystko i nie możemy znaleźć tego, co tak naprawdę "trzyma" nasz katalog
(blokuje przed usunięciem).
Co wtedy? Restart komputera? :) Niekoniecznie. Możemy jeszcze ściągnąć program
ProcessExplorer
i tam wyszukać uchwyt do zblokowanego pliku lub katalogu.
W ten sposób możemy go zamknąć:
W ten sposób przedstawiliśmy trzy najczęściej spotykane problemy na początku pracy z Mavenem. Mamy nadzieję, że choć
trochę ułatwiliśmy Wam życie i oszczędziliśmy nerwów :)
Mapa umiejętności programisty Java
Nie jesteś biegły w Javie?
Interesuje Cię szerszy zakres wiedzy?