Structure du paquet OSGi

Question

J'ai réfléchi aux "bonnes pratiques" concernant la structure des paquets dans les paquets osgi. Actuellement, en moyenne, nous avons 8-12 classes par paquet. Une de mes initiatives/propositions a été d'avoir deux paquets; com.company_name.osgi.services.api (pour les classes/interfaces liées à l'API (qui est exportée en externe) et un package nom.compagnie.osgi.services.impl pour l'implémentation (non exporté)). Quels sont les avantages de cela? D'autres suggestions?

Answer 1

Vous pouvez également envisager de mettre les interfaces dans com.company_name.subsystem, et l'implémentation dans com.company_name.subsystem.impl, le code spécifique OSGI, s'il y en a, pourrait être dans com.company_name.subsystem.osgi. Parfois, vous pourriez avoir plusieurs implémentations des mêmes interfaces. Dans ce cas, vous pourriez envisager - com.company_name.subsystem.impl1 et com.company_name.subsystem.impl2, par exemple:

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 

Dans cette structure de paquet de sens pourrait être agnostique OSGi, si vous plus tard passer à un autre conteneur, vous mettez juste un

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

supplémentaires

Toujours avoir api et impl dans votre nom de package peut être gênant. En cas de doute, utilisez impl mais pas api.

Answer 2

Ce n'est pas le nombre de classes qui est important mais les concepts. À mon avis, vous devriez avoir une entité conceptuelle dans un paquet. Dans certains cas, cela peut être juste quelques classes dans plusieurs autres paquets avec des centaines de classes.

Il est important de séparer l'API et l'implémentation. Un bundle contient l'API de votre concept et l'autre l'implémentation. Vous pouvez ainsi proposer différentes implémentations pour une API bien définie. Dans certains cas, cela peut même être nécessaire si vous souhaitez accéder aux services à distance (par exemple R-OGSi)

Les ensembles d'API sont ensuite utilisés par le partage de code et les services des ensembles d'implémentation par partage de service. La meilleure façon d'explorer ces possibilités est de regarder les ServiceTrackers.

Answer 3

Dans votre cas, vous pourriez avoir l'implémentation dans le même paquet, mais toutes ses classes "paquet protégé". De cette façon, vous pouvez exporter le package et l'implémentation ne sera pas visible à l'extérieur, même si vous n'utilisez pas OSGi (mais en tant que fichier jar standard).