Wersja 3.1 - ostatnia aktualizacja: 20 czerwca 2005
Pakunek może zawierać swój opis w pliku manifestu o nazwie META-INF/MANIFEST.MF. Specyfikacja środowiska OSGi R4 definiuje zbiór nagłówków manifestu, takich jak Export-Package i Bundle-Classpath, które mogą być używane przez programistów pakunków do dostarczania opisów pakunków. Środowisko Eclipse OSGi implementuje pełną specyfikację środowiska OSGi R4 oraz wszystkie usługi środowiska podstawowego. Środowisko podstawowe OSGi R4 zawiera następujące usługi:
W specyfikacji środowiska OSGi R4 zdefiniowano wiele usług opcjonalnych. Usługi opcjonalne nie zostały włączone do implementacji środowiska Eclipse OSGi. Informacje na temat nagłówków manifestu i usług środowiska OSGi R4 zawiera specyfikacja środowiska OSGi R4.
Środowisko Eclipse OSGi obsługuje wiele dodatkowych nagłówków manifestu pakunku i dyrektyw. Programista pakunków może używać tych dodatkowych nagłówków i dyrektyw w celu skorzystania z pewnych dodatkowych funkcji środowiska Eclipse OSGi, które nie zostały określone jako część standardowego środowiska OSGi R4.
Środowisko Eclipse OSGi obsługuje dodatkowe dyrektywy dla nagłówka Export-Package. Dyrektywy te służą do określania reguł ograniczania dostępu dla wyeksportowanego pakietu. Informacje dotyczące konfiguracji środowiska Eclipse OSGi w celu wymuszania reguł ograniczania dostępu w czasie wykonywania znajdują się w sekcji osgi.resolverMode.
Dyrektywa x-internal może zostać użyta w nagłówku Export-Package do określenia, czy dany pakiet jest pakietem wewnętrznym. Środowisko programowania modułów dodatkowych będzie odradzało użycie pakietu wewnętrznego przez inne pakunki. Jeśli nie określono dyrektywy x-internal, użyta zostanie wartość domyślna "false". Dyrektywa x-internal musi mieć następującą składnię:
x-internal ::= ( 'true' | 'false' )
Poniżej przedstawiono przykład dyrektywy x-internal:
Export-Package: org.eclipse.foo.internal; x-internal:=true
Dyrektywa x-friends może zostać użyta w nagłówku Export-Package do określenia listy pakunków, które mogą uzyskać dostęp do pakietu. Środowisko programowania modułów dodatkowych będzie odradzało użycie pakietu przez inne pakunki. Dyrektywa x-friends musi mieć następującą składnię:
x-friends ::= '"' ( pakunek_docelowy ) ( ',' pakunek_docelowy ) * '"' pakunek_docelowy ::= nazwa symboliczna pakunku
Poniżej przedstawiono przykład dyrektywy x-friends:
Export-Package: org.eclipse.foo.formyfriends; x-friends:="org.eclispe.foo.friend1, org.eclipse.foo.friend2"
Powyższy przykład określa, że tylko pakunki org.eclispe.foo.friend1 i org.eclipse.foo.friend2 powinny mieć możliwość używania pakietu org.eclipse.foo.formyfriends. Dyrektywa pakietu x-internal ma wyższy priorytet niż dyrektywa x-friends. Jeśli dyrektywa x-internal ma wartość "true", środowisko programowania modułów dodatkowych będzie odradzało użycie pakietu przez wszystkie pakunki, nawet jeśli zostały one określone z użyciem dyrektywy x-friends.
Nagłówek Eclipse-AutoStart służy do określania, czy pakunek powinien być uruchamiany automatycznie przed uzyskaniem dostępu do pierwszej klasy lub zasobu z tego pakunku. Ta funkcja pozwala platformie Eclipse aktywować pakunki na żądanie, kiedy stają się one potrzebne po raz pierwszy. Dzięki temu modelowi możliwe jest uruchamianie platformy Eclipse z minimalną liczbą aktywnych pakunków. Nagłówek Eclipse-AutoStart musi mieć następującą składnię:
Eclipse-AutoStart ::= ( 'true' | 'false' ) ( ';' 'exceptions' '=' '"' lista_wyjątków '"' ) ? lista_wyjątków ::= rozdzielona przecinkami (",") lista pakietów
Atrybut exceptions służy do określania listy pakietów, które nie mogą aktywować pakunku, kiedy ładowane są z niego klasy lub zasoby. Jeśli w manifeście pakunków nie zdefiniowano nagłówka Eclipse-AutoStart, użyta zostanie wartość domyślna "false". Poniżej przedstawiono przykład nagłówka Eclipse-AutoStart:
Eclipse-AutoStart: true; exceptions="org.eclipse.foo1, org.eclipse.foo2"
Powyższy przykład określa, że dany pakunek musi być aktywowany dla wszystkich klas i zasobów ładowanych z tego pakunku, z wyjątkiem klas i zasobów w pakietach org.eclipse.foo1 i org.eclipse.foo2.
Nagłówek Eclipse-PlatformFilter służy do określania filtru platformy dla pakunku. Wynikiem wartościowania filtru platformy na uruchomionej platformie musi być prawda, aby możliwe było rozwiązanie pakunku. Nagłówek Eclipse-PlatformFilter musi mieć następującą składnię:
Eclipse-PlatformFilter ::= poprawny łańcuch filtru LDAP
Środowisko obsługuje filtrowanie następujących właściwości systemowych:
Poniżej przedstawiono przykład nagłówka Eclipse-PlatformFilter:
Eclipse-PlatformFilter: (& (osgi.ws=win32) (osgi.os=win32) (osgi.arch=x86))
Powyższy przykład określa, że rozstrzyganie pakietu jest możliwe tylko w przypadku następujących właściwości platformy: osgi.ws=win32, osgi.os=win32 i osgi.arch=x86. Innymi słowy, musi to być platforma działająca na architekturze x86, używająca systemu operacyjnego win32 oraz systemu okienkowego win32.
Nagłówek Eclipse-BuddyPolicy służy do określania strategii ładowania znajomych klas dla pakunku. Nagłówek Eclipse-BuddyPolicy musi mieć następującą składnię:
Eclipse-BuddyPolicy ::= ( nazwa_strategii ) ( ',' nazwa_strategii ) * nazwa_strategii ::= ( 'dependent' | 'global' | 'registered' | 'app' | 'ext' | 'boot' | 'parent' )
Poniżej przedstawiono przykład nagłówka Eclipse-BuddyPolicy:
Eclipse-BuddyPolicy: dependent
Nagłówek Eclipse-RegisterBuddy służy do określania listy pakunków, dla których ten pakunek będzie zarejestrowanym pakunkiem znajomym. Nagłówek Eclipse-RegisterBuddy musi mieć następującą składnię:
Eclipse-RegisterBuddy ::= ( pakunek_docelowy ) ( ',' pakunek_docelowy ) * pakunek_docelowy ::= nazwa symboliczna pakunku
Poniżej przedstawiono przykład nagłówka Eclipse-RegisterBuddy:
Eclipse-RegisterBuddy: org.eclipse.foo.bundle1, org.eclipse.foo.bundle2
Nagłówek Eclipse-ExtensibleAPI służy do określania, czy pakunek hosta pozwala pakunkom fragmentu na dodawanie interfejsu API do hosta. Ten nagłówek powinien być używany, kiedy pakunek hosta będzie pozwalał fragmentom na dodawanie pakietów do interfejsu API hosta. Jeśli nie określono tego nagłówka, użyta zostanie wartość domyślna "false". Nagłówek Eclipse-ExtensibleAPI musi mieć następującą składnię:
Eclipse-ExtensibleAPI ::= ( 'true' | 'false' )
Poniżej przedstawiono przykład nagłówka Eclipse-ExtensibleAPI:
Eclipse-ExtensibleAPI: true
Nagłówek Plugin-Class służy tylko do obsługi modułów dodatkowych zaprojektowanych dla platformy Eclipse 2.1. Za jego pomocą można określić nazwę klasy, która zostanie użyta do aktywowania modułu dodatkowego za pomocą starego modelu aktywowania platformy Eclipse 2.1. Nie należy używać tego nagłówka w przypadku nowych pakunków zaprojektowanych dla platformy Eclipse 3.0 lub nowszej. Poniżej przedstawiono przykład nagłówka Plugin-Class:
Plugin-Class: org.eclipse.foo.FooPlugin