Bibliothèques OSGi et héritées

Question

Je me suis penché sur OSGi pendant un moment et je me pose des questions sur la meilleure façon de traiter les bibliothèques «héritées» (qui sont publiées sous forme de fichiers JAR non pas en tant qu'ensembles OSGi).

Selon vous, quelle est la meilleure façon de gérer ces problèmes? Modifier leur fichier manifeste et ajouter l'information minimale spécifique au paquet, puis les reconditionner est ce que je fais pour le moment, mais cela me semble quelque peu erroné. Dois-je simplement utiliser la gestion manuelle des dépendances pour ces fichiers JAR (je fais cela pour les bibliothèques qui ont une forte probabilité d'être utilisées uniquement dans une certaine partie de mon application)? Dans la mesure où ils sont disponibles, j'utilise des bundles pour Eclipse (puisque j'utilise Equinox comme plate-forme OSGi, cela fonctionne bien pour les bibliothèques disponibles en bundles).

Existe-t-il des regroupements de paquets autres que les bundles Eclipse que je devrais connaître?

Answer 1

Le printemps est en train de devenir OSGi, en utilisant Equinox comme plateforme sous-jacente.

http://www.springsource.org/dmserver

Rob Harrop's blog vaut suivant si vous êtes dans l'évolution OSGi.

Et pour répondre à votre question, voici le dépôt bundle OSGi Spring:

http://www.springsource.com/repository/app/

Answer 2

Il y a aussi Eclipse Orbit qui a un certain nombre de faisceaux pré-emballés pour les utilisations d'Eclipse. Et au lieu de modifier directement le manifeste du bundle, vous pouvez créer un bundle wrapper qui fournit le manifeste vous-même, et inclure le Jar tel quel avec un en-tête Bundle-ClassPath: foo.jar. Il est légèrement moins efficace de le faire de cette façon car au moment de l'exécution, le fichier foo.jar est extrait (au moins, sur Equinox) mais il peut être plus facile pour vous de gérer le processus de construction avec cela. Le repo de printemps est également une bonne source de bibliothèques open-source qui ont été OSGi'ified.