En développant vos plug-ins, vous avez peut-être un jour été confronté à une erreur, à première vue obscure, due à une directive singleton soit disant manquante…
En effet, le PDE lève une erreur lorsqu’un plug-in qui n’est pas “singleton” souhaite définir des extensions ou des points d’extension.
Pourquoi, et qu’est-ce au juste que cette directive ?
|
Bundle-SymbolicName: com.acme.module.test; singleton:=true |
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…
Mercredi dernier s’est tenu à Toulouse, dans le bar “le Pakito“, le DemoCamp français destiné à fêter la sortie de Ganymede ce 25 juin (déjà demain, donc !).
Étaient présentes plus d’une vingtaines de personnes, provenant des sociétés Actia, Airbus, Apside, Anyware Technologies, Continental, IBM Rational Software, Mipih/McKesson, Sogeti High-Tech et Vega Technologies SAS.
Il y avait aussi quelques freelancers, et un représentant du site developpez.com, qui avait fait la promotion de l’évènement.
Autour de quelques tapas et d’une bonne bière, ont eu lieu des présentations de :
Les échanges (jusqu’à tard dans la soirée !) entre les différents participants ont permis de confirmer qu’Eclipse est, et reste, une plateforme s’adaptant à tout un tas de projets (gestion hospitalière, cartographie, …) dans lesquels on a envie de tout sauf de réinventer la roue !
Cependant, tout le monde était plutôt d’accord pour dire qu’Eclipse reste, sur certains aspects, trop complexe à mettre en œuvre…
Du coup, vivement le DemoCamp e4…! ![]()
Vous aviez peut-être pu remarquer qu’un concours avait été lancé il y a quelques semaines par Nick Boldt pour que les membres de la communauté Eclipse réalisent des posters pour la sortie de Ganymede.
La soumission de posters est désormais terminée : vous pouvez les voir ici, et voter pour vos trois préférés là-bas ! Attention, clôture des votes le 24 juin !
C’est pas pour dire, mais je trouve qu’il y en a certains qui sont très chouettes ![]()
Les sessions de DemoCamps approchent à grand pas, et la déclinaison française se déroulera cette année à Toulouse !
“Ah super, mais un DemoCamp c’est quoi ?!?” me direz-vous…
Et bien c’est un évènement, plutôt informel, permettant à chacun de présenter des projets basés sur Eclipse, d’échanger ses idées, ses points de vue…
Plusieurs démonstrations d’outils sont déjà prévues pour l’édition toulousaine (Ganymede, migration d’applications vers RCP, approche MDA, …) et, que vous ayiez ou non quelque chose à présenter, vous êtes les très bienvenus !
Début des festivités à 19h, mercredi 18 juin, au restaurant Le Pakito (rue des Filatiers). Pour les footeux, pas d’inquiétude à avoir, la France jouant la veille…
Si vous souhaitez vous inscrire, n’hésitez pas, il suffit de rajouter votre nom et vos coordonnées sur cette page du wiki Eclipse…