Repozytoria pakunków OSGi

Istnieje kilka repozytoriów pełnoprawnych pakunków OSGi (z odpowiednimi nagłówkami w manifeście) dla popularnych projektów otwartych:

• SpringSource Enterprise Bundle Repository (aka BRITS)
• Spring-DM OSGi Repository
• Eclipse Orbit
• Knopflerfish bundle repository
• Apache Felix Commons
• OSGi Bundle Repository (OBR)
  

Naturalnym jest, że skoro pakunki OSGi są zwykłymi plikami jar z odpowiednimi nagłówkami w manifeście (cf. Kolejny łyk OSGi - rozdział 3. Warstwa modułowa) dowolne repozytoria mavenowe (np. http://repo1.maven.org/maven2/) lub dowolne inne udostępniające jary, mogą być używane przy zestawianiu środowiska z wymaganymi zależnościami. Problemem jest określenie zależności między pakunkami poprzez nagłówki Import-Package, Export-Package, Ignore-Package, Private-Package, DynamicImport-Package i in. dla zwykłych plików jar, co nie jest obsługiwane przez Platformę OSGi bez dodatkowej pracy przy ich konfiguracji jako pakunki. Właśnie to jest zaletą pobrania plików jar z w/w repozytoriów - posiadanie gwarancji, że są one poprawnymi pakunkami. Założeniem repozytoriów jest udostępnianie poprawnie skonfigurowanych pakunków ze wszystkimi wymaganymi nagłówkami. Jako, że są to oddzielne repozytoria, zarządzane przez różne osoby, czasami prowadzi to do sytuacji, gdzie pakunek X w repozytorium R1 ma inne wymagania niż pakunek X w repozytorium R2 (niestety w tej chwili nie mogę znaleźć informacji o zgłoszonej rozbieżności między Orbit a BRITS). Światło na ich przydatność może rzucić wątek - BRITS vs. Temporary Spring-DM Repo, gdzie mimo prowadzenia dwóch repozytoriów przez pojedyńczą firmę SpringSource, nawet one mają niepoprawnie zdefiniowane pakunki.

Rozwiązaniem rozmieszczenia pakunków w repozytorium jest specyfikacja OSGi RFC 112 Bundle Repository. Innym sposobem zaradzenia problemom z nieścisłymi deklaracjami pakunków jest projekt Pax URL, który pozwala na instalację dowolnego pliku jar dostępnego poprzez inne protokoły dostępu niż domyślne http czy file, np. classpath, mvn, wrap lub narzędzie bnd. Bez względu jakiego narzędzia zastosujemy, część pracy i tak będziemy musieli wykonać samodzielnie, np. przy wykorzystaniu mechanizmu prześwietlania w Javie (Reflection API), gdzie nazwa klasy podawana jest niejawnie. W takiej sytuacji skorzystanie z gotowego pakunku dla popularnego projektu otwartego z w/w repozytoriów może być najmniej czasochłonnym rozwiązaniem (jeśli istnieje).

Zabawa dla wytrwałych i dociekliwych: Co oznacza skrót BRITS będący alternatywną nazwą dla repozytorium SpringSource Enterprise Bundle Repository? (odpowiedzi można szukać w SpringSource Application Platform ships).