Versione 3.1 - Ultima revisione 20 giugno, 2005
Un insieme può riportare le proprie informazioni descrittive nel file manifest denominato META-INF/MANIFEST.MF. La specifica del framework OSGi R4 definisce una serie di intestazioni manifest, quali Export-Package e Bundle-Classpath, utilizzate dagli sviluppatori di insiemi per fornire informazioni descrittive su un insieme. Il framework OSGi di Eclipse implementa la specifica completa del framework OSGi R4 e tutti i servizi del framework principale. Il framework principale OSGi R4 include i seguenti elementi:
Nella specifica OSGi R4 sono definiti numerosi servizi facoltativi. I servizi facoltativi non sono inclusi nell'implementazione del framework OSGi di Eclipse. Per informazioni sulle intestazioni e sui servizi del manifest OSGi R4, fare riferimento alla specifica OSGi R4.
Il framework OSGi di Eclipse supporta numerose altre intestazioni e direttive del manifest di insieme. Uno sviluppatore di insiemi può utilizzare queste ulteriori intestazioni e direttive per trarre vantaggio da alcune funzioni aggiuntive del framework OSGi di Eclipse che non sono specificate come parte del framework OSGi R4 standard.
Il framework OSGi di Eclipse supporta ulteriori direttive sull'intestazione Export-Package. Queste direttive sono utilizzate per specificare le regole sulle limitazioni di accesso di un pacchetto esportato. Per configurare il framework OSGi di Eclipse per applicare le regole sulle limitazioni di accesso al runtime, fare riferimento a osgi.resolverMode.
La direttiva x-internal può essere utilizzata in un'intestazione Export-Package per specificare se il pacchetto è di tipo interno. PDE (Plug-in Development Environment) sconsiglia l'utilizzo di un pacchetto interno da parte di altri insiemi. Se non è stata specificata la direttiva x-internal, viene utilizzato il valore predefinito 'false'. La direttiva x-internal deve utilizzare la seguente sintassi:
x-internal ::= ( 'true' | 'false' )
Di seguito è riportato un esempio di direttiva x-internal:
Export-Package: org.eclipse.foo.internal; x-internal:=true
La direttiva x-friends può essere utilizzata in un'intestazione Export-Package per specificare un elenco di insiemi ai quali è consentito l'accesso al pacchetto. PDE (Plug-in Development Environment) sconsiglia l'utilizzo di un pacchetto da parte di altri insiemi. La direttiva x-friends deve utilizzare la seguente sintassi:
x-friends ::= '"' ( target-bundle ) ( ',' target-bundle ) * '"' target-bundle ::= un nome simbolico di insieme
Di seguito è riportato un esempio di direttiva x-friends:
Export-Package: org.eclipse.foo.formyfriends; x-friends:="org.eclispe.foo.friend1, org.eclipse.foo.friend2"
L'esempio specifica che solo agli insiemi org.eclispe.foo.friend1 e org.eclipse.foo.friend2 dovrebbe essere permesso l'utilizzo del pacchetto org.eclipse.foo.formyfriends. Il pacchetto x-internal ha la priorità sulla direttiva x-friends. Se la direttiva x-internal specifica 'true', PDE sconsiglierà l'utilizzo del pacchetto da parte di altri insiemi, anche se questi sono specificati come amici (friend).
L'intestazione Eclipse-AutoStart viene utilizzata per specificare se un insieme deve essere avviato automaticamente prima che l'insieme acceda alla prima classe o risorsa. Questa funzione consente a Eclipse di attivare gli insiemi su richiesta, la prima volta che sono necessari. Utilizzando questo modello, Eclipse può essere avviato con il minor numero possibile di insiemi. L'intestazione Eclipse-AutoStart deve utilizzare la seguente sintassi:
Eclipse-AutoStart ::= ( 'true' | 'false' ) ( ';' 'exceptions' '=' '"' exceptions-list '"' ) ? exceptions-list ::= un elenco di pacchetti separati da virgole ','
L'attributo 'exceptions' viene utilizzato per specificare un elenco di pacchetti che non attivano l'insieme quando si caricano le relative classi o risorse. Se l'intestazione Eclipse-AutoStart non è definita in un manifest di insieme, viene utilizzato il valore predefinito 'false'. Di seguito è riportato un esempio di intestazione Eclipse-AutoStart:
Eclipse-AutoStart: true; exceptions="org.eclipse.foo1, org.eclipse.foo2"
L'esempio specifica che questo insieme deve essere attivato per qualsiasi classe o risorsa caricata dall'insieme, tranne le classi e le risorse nei pacchetti 'org.eclipse.foo1' e 'org.eclipse.foo2'.
Eclipse-PlatformFilter viene utilizzata per specificare un filtro di piattaforma per un insieme. Un filtro di piattaforma deve essere valutato "true" in una piattaforma in esecuzione affinché sia possibile risolvere l'insieme. L'intestazione Eclipse-PlatformFilter deve utilizzare la seguente sintassi:
Eclipse-PlatformFilter ::= una stringa di filtro LDAP valida
Il framework supporta il filtro sulle seguenti proprietà di sistema:
Di seguito è riportato un esempio di intestazione Eclipse-PlatformFilter:
Eclipse-PlatformFilter: (& (osgi.ws=win32) (osgi.os=win32) (osgi.arch=x86))
Questo esempio specifica che questo insieme può essere risolto solo se le proprietà della piattaforma sono osgi.ws=win32, osgi.os=win32 e osgi.arch=x86. In altri termini, una piattaforma in esecuzione su un'architettura x86, che utilizza un sistema operativo win32 e un sistema di finestre win32.
L'intestazione Eclipse-BuddyPolicy viene utilizzata per specificare i criteri di caricamento di un insieme (buddy loading). L'intestazione Eclipse-BuddyPolicy deve utilizzare la seguente sintassi:
Eclipse-BuddyPolicy ::= ( policy-name ) ( ',' policy-name ) * policy-name ::= ( 'dependent' | 'global' | 'registered' | 'app' | 'ext' | 'boot' | 'parent' )
Di seguito è riportato un esempio di intestazione Eclipse-BuddyPolicy:
Eclipse-BuddyPolicy: dependent
L'intestazione Eclipse-RegisterBuddy viene utilizzata per specificare un elenco di insiemi per i quali questo insieme è registrato come buddy. L'intestazione Eclipse-RegisterBuddy deve utilizzare la seguente sintassi:
Eclipse-RegisterBuddy ::= ( target-bundle ) ( ',' target-bundle ) * target-bundle ::= un nome simbolico di insieme
Di seguito è riportato un esempio di intestazione Eclipse-RegisterBuddy:
Eclipse-RegisterBuddy: org.eclipse.foo.bundle1, org.eclipse.foo.bundle2
Eclipse-ExtensibleAPI viene utilizzato per specificare se un insieme host consente agli insiemi di frammento di aggiungere altre API all'host. Questa intestazione dovrebbe essere utilizzata se un insieme host vuole consentire ai frammenti di aggiungere ulteriori pacchetti all'API dell'host. Se non è stata specificata questa intestazione, viene utilizzato il valore predefinito 'false'. L'intestazione Eclipse-ExtensibleAPI deve utilizzare la seguente sintassi:
Eclipse-ExtensibleAPI ::= ( 'true' | 'false' )
Di seguito è riportato un esempio di intestazione Eclipse-ExtensibleAPI:
Eclipse-ExtensibleAPI: true
L'intestazione Plugin-Class è utilizzata solo per supportare i plugin sviluppati per la piattaforma Eclipse 2.1. Questa intestazione è utilizzata per specificare un nome classe utilizzato per attivare un plugin che utilizza il vecchio modello di attivazione Eclipse 2.1. I nuovi insiemi sviluppati per la piattaforma Eclipse 3.0 o successiva non dovrebbero utilizzare questa intestazione. Di seguito è riportato un esempio di intestazione Plugin-Class:
Plugin-Class: org.eclipse.foo.FooPlugin