Podczas moich ostatnich wojaży z projektami zarządzanymi
Apache Maven 2 potrzebowałem możliwości zdefiniowania różnych konfiguracji dla wtyczki
maven-surefire-plugin. Początkowo rozważałem taką konfigurację:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<excludes>
<exclude>**/WyswietlanieKomunikatowClientTest.java</exclude>
</excludes>
</configuration>
<executions>
<execution>
<id>uruchom-WyswietlanieKomunikatowClientTest</id>
<phase>integration-test</phase>
<configuration>
<includes>
<include>**/WyswietlanieKomunikatowClientTest.java</include>
</includes>
</configuration>
<goals>
<goal>test</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
która oznacza, że domyślne wykonanie wtyczki, np. podczas wykonania
mvn install, wykluczy wykonanie testów z WyswietlanieKomunikatowClientTest, podczas gdy uruchomienie
mvn integration-test, albo wszystkich faz kolejnych, tj.
verify,
install czy
deploy, już tak (warto zajrzeć na strony
Introduction to the Build Lifecycle i
Guide to Configuring Plug-ins#Configuring Build Plugins z dokumentacji Apache Maven, jeśli tematy są niejasne). I tutaj właśnie pojawił się problem - chcąc wykluczyć WyswietlanieKomunikatowClientTest musiałem wykonywać fazy niższe niż
integration-test, a one wykluczają
install. I na odwrót, wykonanie
install wykona
integration-test, a to nie było mi na rękę.
Zacząłem przeszukiwać Internet w poszukiwaniu rozwiązania dla konfiguracji bez
phase w ramach
execution wtyczki. Sądziłem, że gdzieś wokół takiego myślenia powinienem znaleźć rozwiązanie. I jakież było moje zdumienie, kiedy trafiłem na dokument
Default Plugin Execution IDs, gdzie przeczytałem o podobnych dywagacjach. To odpowiadało moim potrzebom! Lektura dokumentu upewniła mnie, że mam szansę coś znaleźć w Mavenie. Na końcu dokumentu, w sekcji
References, było wskazanie na dwa zgłoszenia JIRA dla Apache Maven. Pierwsze
MNG-3401 niezwykle obiecujące, ale kolejne
MNG-3203 odpowiadało dokładnie temu, czego poszukiwałem. Oba rozwiązane tyle tylko, że...
"This should work both in Maven 2.2.0 and in Maven 3.x". U mnie niestety Maven w wersji 2.1.0:
$ mvn -v
Apache Maven 2.1.0 (r755702; 2009-03-18 20:10:27+0100)
Java version: 1.6.0_14
Java home: c:\apps\java6\jre
Default locale: en_PL, platform encoding: Cp1250
OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
Sądziłem, że pracuję z najnowszą wersją Mavena, więc nietrudno sobie wyobrazić, jak wielkie zrobiłem oczy, kiedy zobaczyłem, że wersja 2.2.1 jest już dostępna. To było dokładnie to, czego poszukiwałem. Rozwiązanie na miarę. Instalacja nowej wersji Apache Maven 2.2.1
$ mvn -v
Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.6.0_14
Java home: c:\apps\java6\jre
Default locale: en_PL, platform encoding: Cp1250
OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
zmiana konfiguracji projektu na następującą:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<executions>
<execution>
<id>default-cli</id>
<configuration>
<excludes>
<exclude>**/WyswietlanieKomunikatowKlientTest.java</exclude>
</excludes>
</configuration>
</execution>
<execution>
<id>default-test</id>
<configuration>
<includes>
<include>**/WyswietlanieKomunikatowKlientTest.java</include>
</includes>
</configuration>
<goals>
<goal>test</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
i jestem w domu! Problem rozwiązany! Teraz każdorazowe uruchomienie
mvn install wykona konfigurację o identyfikatorze
default-cli, a każdorazowe wykonanie
mvn test, czyli dosłowne uruchomienie wtyczki surefire, która jest związana z fazą test, wykona konfigurację
default-test. Dokładnie tak, jak sobie życzyłem. Warto zajrzeć do przykładowego wykonania obu poleceń i prześledzić wykonywanie wtyczek i ich execution, aby dokładnie poznać różnicę między nimi. Nie ma to jak rozwiązanie problemu w przysłowiowe 5 minut - dobrze zadane zapytanie w Google...bezcenne! :)
p.s. Jak tak dalej pójdzie, to niedługo zejdę na serce. Tyle wrażeń jednego dnia na pewno niekorzystanie wpływa na moje zdrowie :) A to tylko przy takim, pojedynczym wydarzeniu, a przecież nie było ono moim jedynym. Informatycy to strasznie podatny na zawał serca lud ;-)
p.s.2. Skoro przy temacie zarządzania projektami, to natrafiłem ostatnio na
gradle. Używa ktoś tego? Chętnie wysłucham wrażeń. Komentarze, listy na priv mile widziane.
Uzupełniam dane projektu przyszłej wtyczki - Project name ustawiam na ejb-client i wybieram Target Platform jako an OSGi framework: standard (ktoś wie, co to oznacza i czego nie mam w porównaniu z Equinox?).
Kolejny ekran bez zmian
i w następnym Templates wybieram Hello OSGi Bundle.
Super te szablony, bo z nimi stworzenie bardziej wyrafinowanej wtyczki (wszystkie poza wspomnianym Hello OSGi Bundle) sprowadza się do odpowiedniego wyboru. Nie trzeba nawet wiedzieć, co to są pakunki, aby je stworzyć!
Kiedy pojawi się pytanie o przełączenie perspektywy na Plug-in Development
wciskam Yes i w końcu mam swój wymarzony pakunek OSGi.
Teraz można dalej się bawić w tworzenie bardziej wyrafinowanych elementów pakunku, a na uznanie zasługują dwie rzeczy - edytor MANIFEST.MF (patrz zrzut ekranu wyżej) oraz widok Outline (na zrzucie wyżej po prawej).
Mając gotową wtyczkę/pakunek wystarczy File > Export i wybrać Deployable plug-ins and fragments.
Po prostu bajka. Wszystko idzie bez najmniejszych potknięć. W katalogu plugins, poniżej wskazanego katalogu, czeka na nas gotowy do uruchomienia pakunek OSGi.
W łatwy sposób mamy możliwość importu istniejących pakunków oraz definiowania zależności między nimi - określenie importów i eksportów w manifeście.
Tym samym Eclipse IDE 3.6m2 stało się narzędziem numer 1, jeśli chodzi o tworzenie pakunków OSGi.
