Quand devrais-je utiliser Import-Package et quand devrais-je utiliser Require-Bundle?
OSGi permet de déterminer les dépendances via Import-Package, qui connecte simplement un seul package (exporté à partir de n'importe quel bundle), et Require-Bundle, qui connecte aux exportations d'un bundle nommé spécifique.
Lors de la création d’une application Greenfield OSGi, quelle approche dois-je utiliser pour représenter les dépendances? La plupart des bundles seront internes, mais il y aura certaines dépendances sur des bundles externes (open-source).
Je crois que Require-Bundle est une chose Eclipse (qui a maintenant été faite dans la spécification OSGi pour prendre en charge Eclipse). La méthode "pure" OSGi consiste à utiliser Import-Package, car il sépare spécifiquement le package du paquet qui le fournit. Vous devez déclarer les dépendances sur les fonctionnalités dont vous avez besoin (l'API Java fournie par une certaine version d'un certain package) et non sur la provenance de cette fonctionnalité (ce qui ne devrait pas vous intéresser). Ceci maintient la composition des liasses plus flexible.
Analogie JavaScript: cela revient à détecter si un navigateur Web prend en charge une certaine API plutôt que de déduire de ce que la chaîne d'agent utilisateur dit quel type de navigateur il s'agit.
Peter Kriens de l'OSGi Alliance a plus à dire à ce sujet sur le Blog OSGi .
Le seul cas où vous devez utiliser Require-Bundle est que si vous avez des packages fractionnés, il s’agit d’un package réparti sur plusieurs bundles. Les forfaits fractionnés sont bien sûr fortement déconseillés.
Favorisez Import-Package sur Require-Bundle.
Require-Bundle:
- spécifie le paquet explicite (et la version) à utiliser. Si un ensemble requis doit être refactorisé et un package déplacé ailleurs, les personnes à charge devront modifier leur MANIFEST.MF.
- vous donne accès à TOUTES les exportations du paquet, peu importe ce qu'elles sont et que vous en ayez besoin ou non. Si les parties dont vous n'avez pas besoin ont leurs propres dépendances, vous en aurez besoin pour
- les paquets peuvent être réexportés
- bien que découragé, permet l’utilisation de packages fractionnés, c’est-à-dire: un package réparti sur plusieurs bundles
- peut être utilisé pour des dépendances non liées au code, par exemple: ressources, aide, etc.
Paquet d'importation:
- couplage plus lâche, seul le package (et la version) est spécifié et le moteur d'exécution recherche le paquet requis
- Les mises en œuvre réelles peuvent être échangées
- Les paquets dépendants peuvent être déplacés vers différents paquets par le propriétaire du paquet
- Mais nécessite davantage de métadonnées (par exemple, le nom de chaque paquet) à des niveaux de granularité inférieurs
Je pense qu'Import-Package vous donne un couplage plus souple et devrait être préféré. Je l'utilise lorsque je déclare des dépendances sur des paquets que je ne possède pas, tels que slf4j, et je peux permuter les implémentations à ma guise. J'utilise Require-Bundle lorsque la dépendance est quelque chose que je contrôle, comme mes propres bundles, car tout changement important serait passé par moi de toute façon.
Évitez Import-Package. Étant donné que les paquetages établissent des relations multiples entre les ensembles, ils sont sujets à des cycles de dépendance difficiles à détecter et à éviter.
Require-Bundle, d’autre part, fait référence à un seul ensemble, protégeant ainsi les graphes de dépendance de cycles par une vérification triviale du temps de construction . Avec Require-Bundle, il est beaucoup plus facile de construire une architecture en couches avec un niveau d’abstraction inférieur et isolé.
Import-Package devrait être meilleur car, comme dit précédemment, vous pouvez déplacer un paquet d'un paquet à un autre sans changer le MANIFEST.MF du client existant.
Mais...
Il existe une raison pratique d'utiliser Require-Bundle si vous utilisez Eclipse pour développer vos offres groupées:
Eclipse n'utilise pas les packages comme unités de résolution. Il utilise des paquets. En d'autres termes, si vous utilisez un package d'un ensemble, Eclipse le compile sans signaler de problème d'utilisation du reste des packages non importés à partir de cet ensemble.
Vous pourriez (vous êtes humain) penser que tout va bien et télécharger votre bundle pour le déploiement mais ... votre bundle se cassera au moment de l'exécution.
J'en suis sûr car ce problème est arrivé (à moi!) Aujourd'hui.
La bonne solution serait de changer le conteneur Eclipse Classpath mais ... si cela ne se fait pas ... vous pouvez décider d'éviter ce genre de problèmes nécessitant des paquets, au lieu des paquets, en payant le prix mentionné (pas de compatibilité ascendante mouvement de code entre les paquets).