Ustawienia globalne a ustawienia użytkownika
Na początku warto zaznaczyć, że ustawienia (settings.xml) znajdują się w dwóch miejscach, co też odzwierciedla ich znaczenie:
Ustawienia globalne – znajdują się w katalogu instalacji Mavena conf/settings.xml
Ustawienia użytkownika – znajdują się w katalogu .m2/settings.xml użytkownika
Ustawienia globalne są dziedziczone w każdych ustawieniach użytkownika gdzie mogą być nadpisane.
Podstawowe ustawienia
W pliku settings.xml możemy ustawić takie ustawienia jak:
localRepository – jest to ścieżka do lokalnego repozytorium
interactiveMode – czy Maven ma pytać użytkownika o wartości czy ma korzystać z domyślnych ustawień
offline – czy Maven może próbować łączyć się z siecią czy nie
Domyślne wartości parametrów są przedstawione poniżej (i są do znalezienia w domyślnym pliku settings.xml dla ustawień globalnych):
...
<settings ...>
<localRepository>${user.home}/.m2/repository</localRepository>
<interactiveMode>true</interactiveMode>
<offline>false</offline>
</settings>pluginGroups – ustawienia wtyczek dostępnych z poziomu linii komend
Aby móc korzystać z wtyczek (plugins) w skróconej wersji z poziomu linii komend należy je wylistować właśnie w sekcji pluginGroups. Powoduje to, że niezależnie w jakim projekcie jesteśmy, będziemy mieli do nich dostęp. Przykładowo chcąc móc uruchomić wtyczkę jetty z jej komendą run w dowolnym projekcie – czyli:
mvn jetty runNależy dodać tą wtyczkę do sekcji pluginGroups:
...
<settings ...>
<pluginGroups>
<pluginGroup>org.eclipse.jetty</pluginGroup>
</pluginGroups>
</settings>Zysk jaki dostajemy jest taki, że nie trzeba wpisywać pełnej grupy przy używaniu wtyczki w różnych miejscach.
Wersja
Co może zastanawiać to wersja wtyczki z jakiej skorzysta Maven. Wtyczki są pobierane automatycznie z najnowszą ich wersją dostępną w pliku maven-metadata.xml (przykład takiego pliku – https://repo.maven.apache.org/maven2/org/eclipse/jetty/jetty-maven-plugin/maven-metadata.xml)
Domyślnie dodane wtyczki
Warto zauważyć, że mimo tego, że jeśli, ani w ustawieniach globalnych ani w ustawieniach użytkownika nie są wprowadzone wtyczki do takich komend jak clean czy install, to wszystko ładnie bez problemu jeśli uruchomimy na przykład polecenie mvn clean install. Dzieje się tak, ponieważ do sekcji pluginGroups dodawane są domyślne wtyczki org.apache.maven.plugins oraz org.codehaus.mojo:
...
<settings ...>
<pluginGroups>
<pluginGroup>org.apache.maven.plugins</pluginGroup>
<pluginGroup>org.codehaus.mojo</pluginGroup>
</pluginGroups>
</settings>
* Oczywiście nie ma potrzeby jawnego dodawania tych wtyczek. Powyższy przykład tylko obrazuje jak to mogłoby wyglądać, gdyby trzeba było wpisywać domyślne wartości ręcznie.
Proxy – przechodzenie przez pośrednika
Maven wspiera także możliwość obsługi proxy. Te ustawienia mogą być używane tylko przy korzystaniu z zasobów sieciowych. Użycie sekcji proxy wraz z jej aktywacją powoduje, że wszystkie próby pobierania z sieci będą kierowane pod skonfigurowany adres url:
...
<settings ...>
<proxies>
<proxy>
<id>optional</id>
<active>true</active>
<protocol>http</protocol>
<username>proxyuser</username>
<password>proxypass</password>
<host>proxy.host.net</host>
<port>80</port>
<nonProxyHosts>local.net|some.host.com</nonProxyHosts>
</proxy>
</proxies>
</settings>
Kluczowa jest tutaj flaga active – dopiero jak jest ustawiona na wartość true, wtedy Maven bierze pod uwagę dane proxy. Id pełni tutaj tylko standardową rolę – pozwala na rozróżnienie różnych konfiguracji proxy. Reszta parametrów mówi sama za siebie.
Login i hasło w sekcji servers
Z racji tego, że login i hasło (lub inne sposoby autentykacji) nie powinny być umieszczane w plikach projektowych (przykładowo w pliku pom.xml). Ustawienia te powinny być umieszczone w sekcji servers:
...
<settings ...>
<servers>
<server>
<id>deploymentRepo</id>
<username>repouser</username>
<password>repopwd</password>
</server>
<server>
<id>testRepo</id>
<privateKey>/path/to/private/key</privateKey>
<passphrase>optional</passphrase> <!-- moze byc puste-->
</server>
</servers>
</settings>Każda sekcja server zawiera id, które powinno być identyczne z id repozytorium, którego dotyczy (repozytorium może być zdefiniowane również na poziomie pliku pom.xml i wtedy obowiązuje ta sama zasada):
...
<settings ...>
<servers>
<server>
<id>deploymentRepo</id>
...
</server>
</servers>
<profiles>
<profile>
<id>profileId</id>
<repositories>
<repository>
<id>deploymentRepo</id>
...
</repository>
</repositories>
</profile>
</settings>Sprytne przekierowanie repozytoriów – mirror
Podobnie jak w przypadku sekcji proxies, sekcja mirrors pozwala na przekierowanie ruchu sieciowego. Aczkolwiek w tym przypadku posiadamy bardziej wyrafinowaną obsługę przekierowań – możemy różne adresy (lub też dopasowania do wzorca – patrz sekcja Advanced Mirror Specification w dokumentacji) przekierowywać w inne miejsca. W skład ustawień pojedynczego bloku mirror wchodzą:
id – powinno być dopasowane do server.id z sekcji servers, tak aby skorzystać z konfiguracji autentykacji
name – przyjazna dla użytkownika nazwa (może zawierać białe znaki)
mirrorOf – pozwala na określenie jaki ruch sieciowy nas interesuje (przykładowo central lub repo1,repo2 lub external:* -> patrz tutaj po więcej)
url – na jaki adres ma być przekierowanie
Przykładowa konfiguracja, przekierowująca wszystkie żądania do repozytorium foo na adres http://repo.dradowiecki.pl/proxy:
...
<settings ...>
<mirrors>
<id>foo-to-dr</id>
<name>Przekierowanie z foo na http://repo.dradowiecki.pl/proxy</name>
<url>http://repo.dradowiecki.pl/proxy</url>
<mirrorOf>foo</mirrorOf>
</mirrors>
</settings>Przekierowanie całego ruchu za pomocą sekcji mirrors
Aby przekierować cały ruch pod dany url należy użyć gwiazdki (patrz mirrorOf) zwanej dziką kartą:
...
<settings ...>
<mirrors>
<mirror>
<id>all-to-dr</id>
<name>Przekierowanie każdego repozytorium na http://repo.dradowiecki.pl/proxy</name>
<url>http://repo.dradowiecki.pl/proxy</url>
<mirrorOf>*</mirrorOf>
</mirror>
</mirrors>
</settings>Profiles – uproszczona wersja profilu z pom.xml
Jest to sekcja pozwalająca na zdefiniowanie profili, lecz jest ona uproszczona w stosunku do standardowych profili definiowanych w plikach pom.xml. Zawiera jedynie takie ustawienia jak:
id – unikalny identyfikator profilu
activation – określa kiedy profil ma być aktywny
properties – sekcja pozwala na zdefiniowanie par klucz-wartość
repositories – określa repozytoria, z których będą zaciągane artefakty
pluginRepositories – określa repozytoria, z których będą zaciągane wtyczki
Dokładny opis poszczególnych elementów profilu znajdziesz tutaj. Przykładowa konfiguracja:
...
<settings ...>
<profiles>
<profile>
<id>someProfile</id>
<activation>
<jdk>1.5</jdk> <!-- aktywuje się dla Javy 1.5-->
</activation>
<properties>
<log4j.version>1.22</log4j.version> <!-- później można tego użyć za pomocą ${log4j.version} -->
</properties>
<repositories>
<repository>
<id>myRepo</id>
<name>User friendly name</name>
<releases>
<enabled>false</enabled>
<updatePolicy>always</updatePolicy>
<checksumPolicy>warn</checksumPolicy>
</releases>
<snapshots>
<enabled>true</enabled>
<updatePolicy>never</updatePolicy>
<checksumPolicy>fail</checksumPolicy>
</snapshots>
<url>http://repo.dradowiecki.pl/repo</url>
<layout>default</layout> <!-- może być też legacy w przypadku starszych wersji Mavena a co za tym idzie innej struktury -->
</repository>
</repositories>
</profile>
</profiles>
</settings>Ustawianie aktywnych profili
Sekcja activeProfiles pozwala na ustawienie aktywnych profili (o ile takie istnieją – jeśli nie istnieją to po prostu nie są uruchamiane). Takie profile będą automatycznie uruchamiane podczas uruchamiania wtyczek. W sekcji tej podawane są identyfikatory profili (profile.id):
...
<settings ...>
<activeProfiles>
<activeProfile>someProfile</activeProfile>
</activeProfiles>
</settings>