Qual è il metodo standard per raggruppare le librerie dipendenti da OSGi?

Question

Ho un progetto che fa riferimento a un numero di librerie open source, alcune nuove, altre non così nuove. Detto questo, sono tutti stabili e desidero attenermi alle versioni scelte finché non avrò il tempo di migrare alle versioni più recenti (ho testato ieri hsqldb 2.0 e contiene molte modifiche API).

Una delle librerie che ho voluto incorporare è Jasper Reports, ma come tutti voi sicuramente sapete, viene fornito con una montagna di file jar di supporto e ho solo bisogno di un sottoinsieme della montagna (noto) quindi sto pianificando per il pacchetto personalizzato di tutte le mie librerie dipendenti.

Quindi:

• Ha tutti abitudine-faccia i propri fasci OSGi per librerie open-source che stanno utilizzando o c'è una fonte maestro di versioni OSGi di librerie comuni?

• Inoltre, stavo pensando che sarebbe molto più semplice per ciascuno dei miei pacchetti semplicemente incorporare i propri barattoli dipendenti all'interno del pacchetto stesso. È possibile? Se scelgo di incorporare le librerie di focalizzazione di terze parti all'interno di un pacchetto, presumo che avrò bisogno di produrre 2 file jar, uno senza le librerie incorporate (per le librerie da caricare tramite classpath tramite il classloader standard) e una versione di osgi che include la libreria incorporata, quindi dovrei scegliere un nome di bundle come questo < <myprojectname> > - < <sottoprogetto> > -osgi-.1.0.0.jar?

• Se non riesco ad incorporare le librerie open source e scelgo di raggruppare in modo personalizzato le librerie open source (tramite bnd), dovrei scegliere un nome bundle univoco per evitare conflitti con un possibile bundle ufficiale? per esempio. < <MyProjectName> >-< <3rdpartylibname> >-< <3rdpartylibversion> > .jar?

• Il mio progetto non abilitato a OSGi attualmente esegue la scansione di plug-in personalizzati tramite la scansione delle cartelle META-INF nei miei vari jar di plugin tramite Service.providers (...). Se vado OSGi, funzionerà ancora questo meccanismo?

Answer 1

Preferisco non incorporare i vasi dipendenti (sì è possibile). Causa due problemi,

1) Non è possibile riutilizzare questo codice. Molti pacchetti possono semplicemente fare la stessa cosa (incorporare lo stesso barattolo) e si finisce con lo stesso barattolo installato molte volte. Puoi sostenere che il tuo bundle può esportare le interfacce anche per il jar incorporato, ma questo diventa brutto in quanto non dovrebbe essere la responsabilità del bundle esporre quel codice. Inoltre, rende più semplice l'esposizione di più versioni della libreria o più provider della stessa versione.

2) Questo è specifico di Eclipse - I jar incorporati non vengono risolti correttamente nell'ambiente di sviluppo (funziona ancora in fase di esecuzione). Il mio bundle potrebbe dipendere da un bundle nella mia piattaforma di destinazione e non riuscirà a risolvere gli elementi nei jar incorporati, per cui devono essere importati nello spazio di lavoro.

Ho scoperto che la maggior parte dei barattoli open source è già stata gentilmente offerta bundled by the nice folks at Spring. Ci sono anche altri repository disponibili, ma sfortunatamente ho perso i miei link.

Answer 2

Forse stai cercando qualcosa come Maven? Non sono sicuro di come funzionerebbe con OSGi. È possibile trovare alcune informazioni su Jasper Reports con Maven qui: http://mvnrepository.com/artifact/jasperreports/jasperreports

Answer 3

progetto Orbit The Eclipse ha anche fatto fasci di molti vasi di terze parti comunemente usati.

http://www.eclipse.org/orbit/

Answer 4

per essere precisi circa le domande che hai chiesto.

Ognuno non fa il suo. Vedere la mia risposta precedente per un collegamento al pacchetto Eclipse di librerie di terze parti come pacchetti. Se non riesci a trovare la versione già confezionata, dovrai crearne una tua.

È meglio racchiudere le dipendenze binarie nel proprio bundle piuttosto che includere il jar come binario nel pacchetto di codice. Scegli il nome del pacchetto che desideri, le importazioni e le esportazioni del pacchetto che contano. Namespacing il nome del bundle con il nome del progetto assicurerà di non colpire collisioni.

Ottenere l'accesso alla zona di stoccaggio pacchetto per la scansione non è impossibile, ma tende a richiedere OSGi runtime informazioni specifiche su come/dove i fasci vengono estratti. Quindi è possibile, ma non facile.

Answer 5

primavera ha creato fasci OSGi della maggior parte delle librerie open source e vedo jasperreports in là. controlla il repository del bundle @http://www.springsource.com/repository/app/bundle

Answer 6

usiamo Maven con OSGI, dichiariamo le dipendenze del bundle nel suo pom.xml e non devi più preoccuparti di esse.