OSGI - gestione di JAR di terze parti richiesti da un pacchetto

Question

Sono appena iniziato con lo sviluppo di OSGI e sto lottando per capire come meglio gestire i JAR dipendenti.

Ad esempio, se sto creando un pacchetto, è probabile che sarà necessario utilizzare alcuni JAR di terze parti. Quando creo il mio JAR in bundle per la distribuzione su OSGI, ovviamente questi JAR di terze parti non sono inclusi e quindi il pacchetto non verrà eseguito.

Capisco che un'opzione è quella di trasformare questi JAR in bundle e anche distribuirli nel contenitore OSGI. Tuttavia, se devono essere utilizzati solo da un pacchetto, questo non sembra ideale.

Qual è la soluzione migliore? I JAR possono essere incorporati all'interno del bundle JAR e, in tal caso, si tratta di un approccio ragionevole?

Answer 1

Vorrei quasi sempre raggruppare ciascun barattolo separatamente. OSGi stesso è pensato per la modularizzazione e tu prendi l'intero sistema ad absurdum non facendolo.

Se si desidera convertire JAR in pacchetti, è possibile utilizzare lo BND Tool written by Peter Kriens. Ma prima vorrei suggerire di cercare il pacchetto nello SpringSource Enterprise Bundle Repository se non hanno già fatto il lavoro per voi.

Answer 2

È possibile incorporare le dipendenze non OSGi nel pacchetto.

Un modo semplice per farlo consiste nell'utilizzare Maven per gestire le dipendenze e Maven Bundle Plugin per creare il pacchetto. Dai un'occhiata alle istruzioni <Embed-Dependency> e <Embed-Transitive> del Plugin Bundle Maven descritto nella sezione Embedding dependencies della pagina di documentazione dei plug-in.

Come ha sottolineato Roland, questa non è una soluzione ideale per quanto riguarda le intenzioni di OSGi, ovvero la modularizzazione e il riutilizzo dei singoli moduli. Tuttavia potrebbe essere una soluzione pragmatica per il tempo fino a quando le dipendenze di terze parti possono essere convertite in bundle OSGi.

Answer 3

È possibile includere un terzo barattolo parte all'interno del vostro pacco con l'aggiunta del terzo barattolo parte alla directory radice del file jar fascio e quindi aggiungendo un colpo di testa fascio classpath per manifesta del pacchetto, ad esempio:

Bundle-ClassPath: .,my3rdparty.jar 

Se si desidera posizionare barattolo di terze parti per sottodirectory specificare il percorso senza l'utilizzo di voce ./, ad esempio

Bundle-ClassPath: .,lib/my3rdparty.jar # (not ./lib/my3rdparty.jar) 

Answer 4

Questo thread è un po 'vecchio, ma ho voluto sottolineare uno dei limiti di incorporare Depen denze. Ricorda che le dipendenze sono a livello di jar, ma quando esporti pacchetti alcuni potrebbero aver bisogno di provenire dalle dipendenze incorporate. Se ciò accade, ti ritroverai con classi duplicate, un set in linea nel bundle di livello superiore e un altro nel jar incorporato. Naturalmente, puoi allineare l'intero jar incorporato, ma prima che tu lo sappia questo si diffonde attraverso l'intera catena di dipendenze. Questo è solo uno dei problemi a cui Roland e altri si riferiscono.

Answer 5

Ecco un esempio se si utilizza lo Maven Bundle Plugin.

Nota: questo plug-in consente di importare automaticamente i pacchetti necessari alle proprie dipendenze. Questo potrebbe o non potrebbe essere un problema per te. Per fortuna, puoi sopprimere i pacchetti che non hai davvero bisogno di importare (vedi sotto).

<Import-Package> 
     <!-- this was imported by one of the dependencies; I don't really need it --> 
     !org.apache.jackrabbit.test, 
     * 
    </Import-Package> 
    <Include-Resource> 
     lib/concurrent-1.3.4.jar, 
     lib/jackrabbit-core-2.6.5.jar, 
     lib/jackrabbit-spi-2.6.5.jar, 
     lib/jackrabbit-spi-commons-2.6.5.jar, 
     lib/lucene-core-3.6.0.jar, 
     lib/tika-core-1.3.jar 
    </Include-Resource> 
    <Bundle-ClassPath> 
     ., 
     concurrent-1.3.4.jar, 
     jackrabbit-core-2.6.5.jar, 
     jackrabbit-spi-2.6.5.jar, 
     jackrabbit-spi-commons-2.6.5.jar, 
     lucene-core-3.6.0.jar, 
     tika-core-1.3.jar 
    </Bundle-ClassPath> 

Answer 6

possiamo usare OSGi per sostituire i barattoli di bootstrap classloader caricati in fase di runtime, come se volessimo ignorare JAXP1.4.5 disponibile con Java7 per JAXP1.6, c'è caratteristica -Dendorese per ignorare l'API di default aggiornato API. Possiamo fare questa cosa con l'aiuto di OSGI.