Versioni dei pacchetti e dei bundle

Ogni bundle o pacchetto di esportazione ha un numero di versione in un formato specifico e ogni dichiarazione di pacchetto di importazione ha un intervallo di versioni. Quando si specifica un intervallo di versioni, è necessario tenere conto delle politiche e delle migliori pratiche attuali, nonché dei requisiti di compatibilità con le versioni precedenti e future.

Numeri di versione

Ogni pacchetto o pacchetto di esportazione ha un numero di versione. Questo numero di versione è composto da un massimo di tre numeri, nel seguente formato:
9.9.9
Il primo numero specifica la componente principale del numero di versione. Il secondo numero (se presente) specifica la componente minore del numero di versione, mentre il terzo numero (se presente) specifica la componente micro del numero di versione. Se si omette un livello di componente, si omette anche il carattere del punto,., che precede quel livello di componente. Ad esempio, i seguenti tre numeri specificano tutti la stessa versione:
9
9.0
9.0.0
Secondo la politica di versioning OSGi, quando una nuova versione di un bundle o di un pacchetto di esportazione non è compatibile con le versioni precedenti, è necessario incrementare il numero di versione principale del bundle o del pacchetto.

Intervalli di versione

Ogni dichiarazione di pacchetto di importazione specifica un intervallo di versioni. L'OSGi Alliance raccomanda la seguente best practice per specificare un intervallo di versioni:
  • Per il limite inferiore dell'intervallo, specificare la versione minima del pacchetto richiesta dal bundle di consumo.
  • Per il limite superiore dell'intervallo, includere qualsiasi versione minore ma escludere qualsiasi incremento nella versione maggiore del pacchetto.
Gli intervalli di versione sono specificati utilizzando la seguente notazione:
  • Una parentesi aperta [ o una parentesi chiusa ] indica che l'intervallo specificato include l'estremità.
  • Una parentesi aperta ( o una parentesi chiusa ) indica l'esclusione della fine dell'intervallo specificato.
Ad esempio, la seguente istruzione di importazione può risolversi con qualsiasi versione di un pacchetto dalla versione 1.0 fino alla versione 2.0, esclusa.
Import-Package: com.myco.a.pkge;version="[1.0,2.0)"

Un pacchetto nella versione 1.3 dovrebbe essere compatibile con un pacchetto nella versione 1.0, quindi un bundle che richiede almeno la versione 1.0 di un pacchetto dovrebbe funzionare se risolto con la versione 1.3 di quel pacchetto. Tuttavia, il bundle potrebbe non funzionare se viene risolto rispetto alla versione 2.0 del pacchetto, quindi la versione 2.0 e le versioni successive sono escluse.

Note:
  • Quando vengono aggiunti nuovi metodi a un'interfaccia, il numero di versione minore viene incrementato per l'intestazione del pacchetto di esportazione. Una classe che implementa la versione precedente dell'interfaccia può funzionare anche con la nuova versione, ma quest'ultima è disponibile solo se specificata esplicitamente. In questo caso, il bundle che importa il pacchetto contenente l'interfaccia dovrebbe specificare, ad esempio, "[1.0,1.1)".

  • Il Java™ Community Process (JCP) non definisce i metadati OSGi, come le versioni dei pacchetti, quando definisce le API. Attualmente, le versioni OSGi sono definite nelle specifiche OSGi che fanno riferimento alle tecnologie Java. Le versioni future delle specifiche JCP dovrebbero essere compatibili con le versioni precedenti, quindi la politica di versioning dei pacchetti OSGi per tali specifiche future potrebbe semplicemente riflettere la versione delle specifiche JCP. Ciò potrebbe comportare una modifica della versione principale di un pacchetto javax anche quando la nuova versione è compatibile con quella precedente. Ad esempio, l'API Java Persistence (JPA) 2.0 è compatibile con la versione precedente JPA 1.0. Ci si potrebbe aspettare che la versione javax.persistence del pacchetto segua il nome della specifica JCP e utilizzi l' 2.0 e della versione. Tuttavia, segue effettivamente la politica di versioning OSGi e utilizza l' 1.1 e di versione.

    Poiché le specifiche JCP cercano sempre di mantenere la compatibilità con le versioni precedenti, è necessario specificare solo la versione minima del javax.* pacchetto e lasciare aperto il limite massimo. Ad esempio, supponiamo che una versione futura di WebSphere® Application Server abbia un provider JPA predefinito che implementa una versione di JPA successiva alla versione 2.0. In questo caso, il server dell'applicazione può esportare il javax.persistence pacchetto in quella versione successiva e continuare a essere risolto dalle applicazioni scritte per funzionare con JPA 1.0 o 2.0. Allo stesso modo, la seguente istruzione di importazione di esempio può risolversi con qualsiasi versione del javax.persistence pacchetto all'indirizzo 1.0 o superiore:
    Import-Package: javax.persistence;version="1.0"