Struttura pacchetto bundle OSGi

Question

Ho pensato ad alcune "buone pratiche" relative alla struttura dei pacchetti all'interno dei bundle di osgi. Attualmente, in media, abbiamo 8-12 lezioni per pacchetto. Una delle mie iniziative/proposte è stata quella di avere due pacchetti; com.company_name.osgi.services.api (per le classi/interfacce relative a API (che vengono esportate esternamente) e un pacchetto com.company_name.osgi.services.impl per l'implementazione (non esportato)). Quali sono i pro contro di questo? Qualche altro suggerimento?

Answer 1

Si potrebbe anche considerare di mettere le interfacce in com.company_name.subsystem e l'implementazione in com.company_name.subsystem.impl, il codice specifico OSGI, se ce n'è, potrebbe essere in com.company_name.subsystem.osgi. A volte potresti avere più implementazioni delle stesse interfacce. In questo caso si potrebbe considerare - com.company_name.subsystem.impl1 e com.company_name.subsystem.impl2, ad esempio:

com.company.scm  // the scm api 
com.company.scm.git // its git implementaton 
com.company.scm.svn // its subversion implementation 
com.company.scm.osgi // the place to put an OSGI Activator 

In questa struttura del pacchetto senso potrebbe essere agnostici OSGi, se in seguito il passaggio a un diverso contenitore, basta mettere un ulteriore

com.company.scm.sca  // or whatever component model you might think of 

Avere sempre api e impl nel nome del pacchetto potrebbe essere fastidioso. In caso di dubbi, utilizzare impl ma non api.

Answer 2

Non è il numero di classi che è importante ma i concetti. Secondo me dovresti avere un'entità concettuale in un pacchetto. In alcuni casi questo potrebbe essere solo alcune classi in altri pacchetti con centinaia di classi.

Ciò che importa è che si separi l'API e l'implementazione. Un pacchetto contiene l'API del tuo concetto e l'altro l'implementazione. In questo modo è possibile fornire diverse implementazioni per un'API ben definita. In alcuni casi questo potrebbe essere addirittura necessario se si desidera accedere ai servizi da un bundle in remoto (utilizzando ad esempio R-OGSi)

I pacchetti API vengono quindi utilizzati dalla condivisione del codice e dai servizi dai pacchetti di implementazione per condivisione del servizio. Il modo migliore per esplorare queste possibilità è guardare i ServiceTrackers.

Answer 3

Nel tuo caso potresti avere l'implementazione nello stesso pacchetto, ma tutte le sue classi "pacchetto protetto". In questo modo, è possibile esportare il pacchetto e l'implementazione non sarebbe visibile all'esterno, anche quando non si utilizza OSGi (ma come un normale file jar).