More specifically, this method will give you the bundle who loaded the given class, or null if the class has not been loaded by the OSGi framework (e.g. if it is a class belonging to the boot classpath…).

Thus, whenever you want to access information such as the version of a bundle, its headers,  etc. without having to query its Activator (perhaps you don’t even have an Activator for this bundle…), you know what you’ve got to use! Of course, whoever says Bundle, means BundleContext, and this handy helper is also very convenient to easily publish/consume OSGi services on behalf of the bundle…

Attention, il faut un compte pour pouvoir télécharger le PDF —et je n’ai pas le droit de le mettre à disposition ici .

En 6 pages, Jeff fait le tour de tous les concepts de base d’OSGi/Equinox, et répond à des questions que tout développeur de bundles OSGi (et plus généralement de plug-ins Eclipse) s’est un jour posé :

• Faut-il préférer l’en-tête Import-Package à Require-Bundle pour la gestion des dépendances?
• Quelle sont les différences entre les services OSGi, les declarative services et les extensions Eclipse? 
• Comment manipuler ses bundles depuis la console OSGi?
• etc.

A lire absolument!

Pourquoi, et qu’est-ce au juste que cette directive  ?

Dans la norme OSGi, il est indiqué que “singleton” (renseigné dans l’entrée de MANIFEST Bundle-SymbolicName) doit être placé à true lorsque l’on souhaite interdire la résolution par le framework de plusieurs versions d’un même bundle.

C’est donc tout à fait logique qu’un plug-in amenant des extensions ou des points d’extension soit impérativement un singleton ; car il serait sans cela très difficile, voire impossible, de gérer les différentes versions résolues au runtime…
Imaginez simplement un plug-in amenant une vue, que l’on pourrait déployer dans deux, trois, … versions différentes au sein du même Eclipse : à quoi devrait-on s’attendre lors de l’affichage du menu “Show View > Other…” ???

Dans le cas où on écrit un plug-in n’amenant ni extension ni point d’extension —un plug-in de librairies, par exemple—, on sera en revanche ravi de pouvoir dire que ce n’est pas un singleton (c’est le comportement par défaut), et ainsi faire coexister différentes versions de nos librairies dans le même Eclipse. C’est d’ailleurs exactement ce qui se passe avec les plug-ins ICU, Ant ou log4j, dont les utilisateurs viennent dépendre en venant préciser le numéro (ou l’intervalle) de version qui les intéresse…

Ce dernier sera disponible sous licence Creative Commons, et le premier chapitre est d’ores et déjà téléchargeable ici.
Si tout va bien, trois chapitres supplémentaires devraient être disponibles dans le courant de cette semaine ; Neil Bartlett encourageant ses lecteurs à contribuer activement à l’ouvrage, en le relisant ou bien en proposant du contenu.

Même si ce ne sont que 25 pages pour l’instant, le style de l’auteur est très agréable, les exemples clairs, et il y a même quelques exercices de mise en pratique à la fin du chapitre !

Ce flux RSS vous permettra d’être tenus au courant dès qu’un nouveau chapitre sera disponible.