Krzysiek Piwoński w komentarzu do poprzedniego wpisu zamieścił wycinek ze swojego env. To spowodowało, że przypomniałem sobie dlaczego jeszcze nie zmigrowalem na maven3 w pracy.

W maven 3 jest trochę zmian. Jedną z bardziej bolesnych jest kompletna zmiana sposobu zarządzania profilami w ramach pliku settings.xml. W maven 2 było tak, że w tagu profile dało się upchnąć m.n. domyślną konfigurację pluginów. W maven 3 nie jest to możliwe, bo o ile jeszcze po umieszczeniu np. tagu build w definicji profilu maven strzeli tylko delikatnego focha w trakcie gry wstępnej i poinformuje nas, że ten tak jest wybitnie nie na miejscu:

Listing 1. Komunikat o niedozwolonym tagu

$ mvn clean
[WARNING] 
[WARNING] Some problems were encountered while building the effective settings
[WARNING] Unrecognised tag: 'build' (position: START_TAG seen ...<id>j7</id>\n\t\t\t<build>... @140:11)  @ /home/koziolek/maven3/conf/settings.xml, line 140, column 11
</build>

To już znacznie większym problemem może okazać się stosowanie takiej metody konfiguracji jako domyślnej np. na serwerze CI. W takim przypadku informacje zawarte w pliku settings.xml zostają olane, a jakaś niewinna duszyczka musi nosić [koszulkę z wyznaniem winy](http://nerdoza.cupsell.pl/produkty/63783-I-broke-a-Build.html), bo akurat to po jej commicie się posypało.

Jak sobie z tym poradzić?

W mavenie 2 mało kto korzystał z expressions do konfiguracji projektu. Zazwyczaj ograniczało się to do użycia ich w celu oznaczanie wersji Springa/Guice czy jakiegoś nietypowego ustawienia dziedziczonego przez kilka pluginów.
Ja wykorzystam je tutaj do eleganckiego zdefiniowania ustawień związanych z różnymi wersjami JVM.

Dodanie konfiguracji do settings.xml

Otwieramy odpowiedni plik settings.xml. Odpowiedni to znaczy:

  • plik umieszczony w $MAVEN\_HOME/conf jeżeli chcemy zastosować konfigurację do wszystkich wywołań mavena niezależnie od użytkownika.
  • plik umieszczony w ~/.m2 jeżeli chcemy zastosować konfigurację tylko do konkretnego użytkownika.

W sekcji settings/profiles dodajemy:

Listing 2. konfiguracja profili

		<profile><id>j6</id><properties><maven.compiler.executable>/home/koziolek/java/bin/javac</maven.compiler.executable><maven.compiler.fork>true</maven.compiler.fork><maven.compiler.source>1.6</maven.compiler.source><maven.compiler.target>1.6</maven.compiler.target></properties></profile><profile><id>j7</id><properties><maven.compiler.executable>/home/koziolek/java7/bin/javac</maven.compiler.executable><maven.compiler.fork>true</maven.compiler.fork><maven.compiler.source>1.7</maven.compiler.source><maven.compiler.target>1.7</maven.compiler.target></properties></profile>

i więcej jak mamy taką potrzebę.

Następnie w sekcji settings/activeProfiles dodajemy

Listing 3. wybór profilu domyślnego

<activeprofile>j6</activeprofile>

Lub jakikolwiek inny, który chcemy używać jako domyślny. Brak wskazania domyślnego profilu skutkuje uruchomieniem każdego builda z konfiguracją domyślną co oznacza m.n. użycie javy w wersji 1.5 (z dokładnością do tego jak działa flaga -target w javac, ale to innsza inszość).

Co oznaczają poszczególne flagi?

  • maven.compiler.source – tak jak source w specyfikacji kompilatora.
  • maven.compiler.target – tak jak target w specyfikacji kompilatora.
  • maven.compiler.executable – pełna ścieżka do pliku kompilatora.
  • maven.compiler.fork – najważniejsza z flag. Powoduje, że proces kompilacji jest uruchamiany jako osobny proces w systemie dzięki czemu można użyć zewnętrznego kompilatora.

Jak widać ostatnia flaga steruje całą magią konfiguracji. Jeżeli przestawimy ją na false to możemy spodziewać się różnych ciekawych efektów ubocznych. Począwszy od kompilacji projektu pod javę 5, poprzez kompilację z użyciem np. Hot-Spot zamiast JRockit, a kończąc na błędach samego kompilatora mówiących, że „sorry cie bardzo nie ta wersja javy”.