Przyszło mi się zmagać z opublikowaniem
Apache OpenEJB 3.0 i podczas budowania wersji dystrybucyjnej zwrócono uwagę, że każdy plik będący w dystrybucji musi posiadać nagłówek z odpowiednią licencją ASLv2, a pliki typu jar czy zip pliki LICENSE oraz NOTICE. OpenEJB jest projektem rządzącym się prawami Apache Software Foundation, więc obowiązują go zasady opisane w dokumencie
ASF Source Header and Copyright Notice Policy. Projekt OpenEJB zarządzany jest przez Apache Maven 2, więc do obsługi wspomnianych plików wykorzystywane są odpowiednie wtyczki - typowe rozwiązanie to kopiowanie ich z katalogu projektu. Nie byłoby w tym nic wyjątkowego, gdyby nie fakt, że plik NOTICE jest zbiorem licencji zależności wykorzystywanych przez projekt OpenEJB. Do dzisiejszej nocy konieczne było umieszczanie informacji o licencjach manualnie - każdorazowe dodanie zależności oraz co najbardziej bolesne zależności przechodnich, tj. takich, które były zależnościami pochodnymi zależności, którą deklaruje projekt, musiało wiązać się z odpowiednią adnotacją w pliku NOTICE. Można sobie wyobrazić, że nie było to przyjemne i podczas tworzenia wersji dystrybucyjnej konieczne było ponowne przeanalizowanie wszystkich zależności i ich licencji oraz dodanie brakujących do NOTICE. Bolesne. Aż do dzisiejszego wieczora, kiedy wykorzystałem wtyczkę
Maven 2 Remote Resources Plugin (MRRP). Jej zadaniem jest automatyczne zarządzanie informacjami, które projekty i tak zobowiązane są umieszczać we własnym pliku pom.xml (serce projektu kontrolowanego przez Apache Maven 2). Wtyczka działa w ten sposób, że pobiera zdalny zestaw plików (parametr konfiguracyjny wtyczki
resourceBundles), które umieszczane są w paczce dystrybucyjnej. Dodatkowo włączany plik może być szablonem Velocity, co daje możliwość modyfikacji jego zawartości na bazie konfiguracji wtyczki. Pozostaje jedynie zapewnić, że wymagane informacje o projekcie ów projekt udostępnia, co sprowadza się do poprawienia ich plików pom.xml albo samodzielne zarządzanie informacjami w pliku
supplemental-models.xml (w katalogu
src/main/appended-resources). Jeśli nawet wtyczka wymaga pewnych kroków konfiguracyjnych, to proces zarządzania dołączanymi plikami (wliczając w to również ich dynamiczną modyfikację) sprowadziła do minimum. Istnieje również możliwość budowania własnych zestawów plików do dołączenia, co przy wielu projektach pozwala na zbudowanie pojedyńczego repozytorium dołączanych dokumentów, a nie wyłącznie plików typu jar, zip, war, ear, itp.
Podczas rozpoznawania jak działa wtyczka MRRP postanowiłem pobrać jej źródła. Nie było ich wiele, więc lektura nie zabrała więcej niż kwadrans. Po ostatnich pozytywnych wrażeniach z pracą NetBeans IDE 6 i wtyczką NetBeans do obsługi projektów zarządzanych przez Maven 2 postanowiłem skorzystać z NetBeans IDE. Nie chciałem jednak zaśmiecać sobie widoku projektów modułów OpenEJB z projektem wtyczki i przypomniałem sobie o funkcjonalności, której nie miałem jeszcze sposobności wykorzystać -
Project Group. Jest to bardzo podobne do przestrzeni roboczych (ang.
workspaces) w Eclipse, czy grupowania projektów w Eclipse w widoku projektów. Zawsze mi tego brakowało w NetBeans, więc teraz przyszła pora na sprawdzenie, czy to jest właśnie to. Zdefiniowałem sobie grupę dla projektu OpenEJB, a drugą dla wtyczki MRRP. Pamiętam podobną funkcjonalność z IntelliJ IDEA, gdzie bodajże już w wersji 4 było to ciekawie rozwiązane, gdzie przełączenie to było jedynie ukrycie projektów, które de facto cały czas były otwarte, albo podobnie. W przypadku NetBeans Project Group działa podobnie. Chciałbym mieć możliwość otwarcia grupy w osobnym oknie NetBeans, więc nie do końca byłem zachwycony, ale ogólnie ocena 4+.
Brak komentarzy:
Prześlij komentarz