Come impacchettare e consumare una libreria Java esistente con OSGI

Question

Dopo aver chiesto aiuto per la gestione delle dipendenze su versioni diverse delle stesse librerie in Java, è stato suggerito di dare un'occhiata alle implementazioni OSGI. Essendo sottoposto a una pressione di scadenza, potrei davvero usare un aiuto che mi eviterebbe di scavare attraverso infiniti documenti OSGI. Ho un'app funzionante, che userà un nuovo framework. Il framework utilizza diverse versioni di jar che sto già utilizzando, quindi voglio impacchettare il nuovo framework come un bundle OSGI. Posso lasciare la mia app così com'è e utilizzare il bundle OSGI solo come contenitore all'interno di JVM? Ciò significherebbe che utilizzerei il bundle OSGI solo per isolare un insieme di classi dal resto della JVM per evitare conflitti tra diverse versioni delle classi. in altre parole, voglio usare OSGI senza portare tutto il mio codice su una configurazione basata su OSGI.

Cordiali saluti Seref

Answer 1

Non ho una risposta completa per voi qui, volevo solo per contrastare ciò che deterb detto:

In primo luogo, si deve avere l'intera applicazione nel quadro OSGi.

Questo non è vero. Un altro approccio sarebbe quello di incorporare un contenitore OSGi in un'applicazione host.

La parte difficile qui è l'interazione tra all'interno di OSGi e all'esterno, perché il codice vive su classloader separati.

È possibile rendere le classi host visibili alla parte OSGi utilizzando il classpath del sistema OSGi. L'altro modo è più difficile.

Un modo per il codice host di interagire con i pacchetti è un'interfaccia visibile sia per l'applicazione host che per il pacchetto, ovvero la parte dell'host. Un altro modo sarebbe usare la riflessione.

Se si dispone di una chiara separazione tra host e OSGi, ad esempio un sistema di plugin, questo potrebbe funzionare abbastanza bene.

Essere sotto pressione scadenza

Questo potrebbe essere un problema. C'è molto da imparare con OSGi, e dal momento che sta per raggiungere il mainstream, c'è ancora una mancanza di conoscenza della comunità, supporto degli strumenti, compatibilità delle librerie e così via.

La domanda più grande che si dovrebbe porre a questo punto è: ho davvero bisogno di gestire diverse versioni di dipendenze in fase di esecuzione? In caso contrario, è possibile capire le cose al momento della distribuzione (ad esempio per configurazione), quindi potrebbe esservi una soluzione più semplice.

Answer 2

In primo luogo, si deve avere l'intera applicazione nel quadro OSGi. Tuttavia, non penso che sarebbe difficile impostarlo in modo tale da dover lavorare solo con alcuni bundle (forse solo due, a seconda dell'impostazione.)

Il percorso con il minor numero di problemi che riesco a vedere sarebbe essere per prendere il framework e "avvolgere" esso e tutte le sue dipendenze in un unico pacchetto.Realizzare i pacchetti per le dipendenze.Per il tuo progetto principale, fare lo stesso

L'altro percorso sarebbe quello di impacchettare tutto librerie separate usando i comandi di wrap appropriati.Questo ha molti più problemi potenziali se non sei interessato ad andare a pieno OSGi.

A seconda della configurazione della tua build, vorrei iniziare dando un'occhiata al maven-bundle-plugin e/o Bnd. Il plug-in Maven-dependency lo rende abbastanza facile, in quanto tutto ciò che devi fare è dirgli quali sono gli artefatti da incorporare e lo farà. Dovrai assicurarti di specificare tutti i pacchetti jar incorporati come pacchetti privati.

Questo dovrebbe funzionare a meno che il framework non stia eseguendo il caricamento di classe/AOP, il che renderebbe molto più difficile OSGify.

Infine, se siete interessati a una soluzione rapida non OSGi, costruire il quadro con la maven-shade-plugin e basta rinominare tutti i pacchetti per le librerie in conflitto. Questo sarebbe probabilmente il più semplice in quanto si dovrebbe semplicemente riconfezionare il framework con le librerie ombreggiate una volta e quindi utilizzarlo come dipendenza.