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 <properties> i w samych zależnościach posługujemy się już parametrami. Np dla kino-dao będzie to wyglądało tak:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>pl.ekaczynski.kino</groupId> <artifactId>kino-dao</artifactId> <version>1.0.0</version> <packaging>jar</packaging> <name>kino-dao</name> <properties> <kino.version>1.0.0</kino.version> <dao-hibernate.version>1.2.0</dao-hibernate.version> <hibernate.version>3.5.0-Final</hibernate.version> </properties> <dependencies> <dependency> <groupId>pl.ekaczynski.kino</groupId> <artifactId>kino-entities</artifactId> <version>${kino.version}</version> </dependency> <dependency> <groupId>com.googlecode.genericdao</groupId> <artifactId>dao-hibernate</artifactId> <version>${dao-hibernate.version}</version> </dependency> </dependencies> </project> |
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.
1 2 3 4 5 6 |
<parent> <groupId>xxxxxx</groupId> <artifactId>yyyyyy</artifactId> <version>zzzzz</version> <relativePath>ścieżka względna do poma rodzica np: ../pom.xml</relativePath> </parent> |
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