Plus précisément, cette méthode vous renverra le bundle qui a servi à résoudre ladite classe, ou null dans le cas où la classe n’a pas été chargée par le Framework (si c’est une classe du boot classpath par exemple…).

Ainsi, dès qu’il s’agira de récupérer des infos comme le numéro de version d’un bundle, ses headers, etc… sans avoir à passer par l’Activator (qui parfois n’existe d’ailleurs même pas…), vous savez ce qu’il vous restera à faire! En outre, qui dit Bundle, dit BundleContext, et cette méthode est donc également un moyen très simple de publier/consommer des services !..

Après trois ans d’activité dans la communauté Eclipse et presque deux ans de « blogging » (pas toujours de façon régulière…) en français, je me lance (et j’en profite pour changer de thème WordPress !)

J’essaierai autant que possible d’écrire mes posts en double, donc pour ceux qui tiennent à continuer à suivre le fil « français », il n’y a rien à changer au niveau de votre agrégateur RSS… Pour les autres, abonnez-vous à http://feeds.feedburner.com/benjamin-cabe_en !

Et pour ceux que ça intéresse, vous pouvez également me suivre surtwitter!

Pour ceux qui sont à la recherche d’un moyen de récupérer facilement les icônes en question en une seule fois, le script suivant peut vous dégrossir le travail, en aspirant les icônes des projets Eclipse qui en contiennent beaucoup, directement depuis le CVS:

[bash]#!/bin/sh
CVSROOT=:pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse
export CVSROOT
mkdir -p eclipse
cd eclipse
cvs -q co org.eclipse.debug.ui/icons
cvs -q co org.eclipse.pde.ui/icons
cvs -q co org.eclipse.jdt.ui/icons
cvs -q co org.eclipse.vcm.ui/icons
cvs -q co org.eclipse.team.ui/icons
cvs -q co org.eclipse.ant.ui/icons
cvs -q co org.eclipse.help.ui/icons
cvs -q co org.eclipse.ui/icons
cvs -q co org.eclipse.ui.views/icons
cvs -q co org.eclipse.ui.console/icons
cd ..
rm -f ~/public_html/eclipse-icons.zip
find eclipse -name "*.gif" -print | zip ~/public_html/eclipse-icons.zip -@
[/bash]

Enfin, de manière générale, le site http://www.iconlet.com peut vous être d’un grand secours. Il permet de rechercher par mot-clé  des icônes et images libres, et d’en connaître instantanément la licence…

Cette année, vous aurez en quelque sorte droit à trois évènements en un puisque la conférence se voit divisée en deux journées (au lieu d’une seule les années précédentes), et que la soirée du 23 juin sera l’occasion de se réunir autour du Galileo DemoCamp français.

• La journée de conférences sera l’occasion pour les participants d’être informés des dernières tendances : implémentation de certains composants, applications développées pour des clients… Elle se tiendra à la Cité de l’Espace et sera animée par des acteurs majeurs du monde Eclipse : membres de la fondation Eclipse, éditeurs de logiciels, industriels utilisateurs d’applications basées sur Eclipse.
• Le DemoCamp sera, comme son nom l’indique, orienté… démos (et bières !). L’objectif sera d’une part de fêter la sortie de Galileo (Eclipse 3.5), mais aussi et surtout de présenter les différents usages qui sont faits des technologies Eclipse.
  Inscrivez-vous dès maintenant si vous avez l’intention de venir (et, encore mieux, de présenter un sujet !). On me glisse dans l’oreillette qu’il sera par exemple montré comment Eclipse peut servir à programmer une brique « Lego Mindstorms », ou comment Eclipse RCP peut être mis en oeuvre pour proposer des interfaces conviviales pour le diagnostic automobile ! Ce DemoCamp se tiendra dans la soirée du 23 juin, à la Cité de l’Espace.
• La session du 24 juin se veut un peu plus technique, et sera découpée en deux demi-journées de formation, permettant aux participants d’aborder le développement orienté composants grâce à OSGi et Equinox, les technologies clients riches sur le marché (Flex, GWT, RAP, …),  le futur Eclipse 4, la réalisation d’IDE à destination du monde de l’embarqué, la mise en oeuvre d’un serveur d’intégration continue d’applications Eclipse RCP avec Hudson, etc.

Pour plus d’informations, et pour vous inscrire, ça se passe ici !

J’espère bien avoir l’occasion de rencontrer certains lecteurs de ce blog lors de l’évènement…

Le 19 mars, à 16h30, je co-animerai avec Vincent Ducrohet de la société Ingres, un webinar destiné à présenter Eclipse (tant l’atelier de développement que la plateforme), le SGBD Open Source Ingres, et les utilisations qui peuvent être faites de ces deux technologies.

Un cas d’utilisation concret d’Eclipse pour la réalisation d’une application métier (plateforme d’analyse et visualisation de données d’observations satellite) sera également exposé sous forme d’une démonstration.

C’est gratuit, et les inscriptions se passent ici !

Au programme, une démo mettant en œuvre les grands principes retenus dans le cadre de cette refonte architecturale qu’est e4, à savoir :

• Le « workbench » de cette démo modélisé de A à Z : les vues, les menus, les commandes attachées aux entrée de ces menus, etc. sont des éléments d’un même modèle, et leur représentation graphique est automatiquement synchronisée avec leur représentation en mémoire (mais pas encore en utilisant l’API de Databinding..!).
  Ainsi, persister l’état de l’application entre deux exécutions devient trivial : il suffit de recharger le modèle que l’on a pris soin de sérialiser lors de l’arrêt de l’application !
• Le styling de l’IHM en utilisant des CSS est supporté, et c’est assez impressionant à voir fonctionner !

En effet, cela fait plusieurs années que le modèle existant a commencé à montrer ses limites : impossibilité d’imbriquer des projets les uns dans les autres, mauvaise gestion des liens symboliques, etc. Il est ainsi désormais possible, par exemple, de créer des « groupes » logiques de ressources, afin de gérer des topologies de projets particulièrement complexes, indépendamment de leur structuration physique.

N’oubliez pas non plus d’aller faire un tour sur la page du wiki qui commence à être assez fournie !

Pendant des années, Eclipse a été livré avec un composant appelé Update Manager, qui permettait aux utilisateurs de mettre à jour leur environnement Eclipse -presque- sans effort. Cependant, au fil des évolutions successives, et en particulier avec l’arrivée de sa version 3.0, Eclipse est devenu bien plus qu’un simple environnement de développement : c’est désormais une véritable plateforme logicielle, basée sur Equinox (l’implémentation Eclipse du standard OSGi). Les besoins en terme de déploiement ne sont donc plus limités à l’installation et la mise à jour de simples plug-ins… Les concepteurs de logiciels basés sur Eclipse doivent pouvoir proposer un installeur de leur produit, qui nécessitera peut-être un gestionnaire de licences qu’il faudra également installer, … et p2 est la plupart du temps la solution à ce type de problématique.

p2: une plateforme de provisioning…

Pour être en mesure de provisionner tout type d’application, l’atout principal de p2 est de ne pas être exclusivement centré sur les environnements Eclipse, ni même sur  les applications Java. Il s’agit d’un simple framework permettant de décrire des éléments à installer, ainsi que leurs dépendances. Ce framework vient avec des implémentations-type permettant d’installer des modules OSGi ou des produits RCP, mais guère plus. Il appartient ensuite aux vendeurs de logiciels qui souhaiteraient, par exemple, installer un exécutable Windows en même temps que leur application Eclipse RCP, d’écrire du code spécifique (en fait, un plug-in p2 !), pour réaliser cette installation correctement.

….en mesure de devenir le prochain standard de déploiement ?

Bien entendu, p2 est encore un jeune projet et peut ne pas sembler assez mature pour être utilisé dans une logique industrielle (pas toujours totalement fiable, outils parfois manquants, …), mais la qualité de cette première version est particulièrement prometteuse. Depuis sa sortie, p2 a su fédérer une communauté d’utilisateurs qui commence à le mettre à profit dans d’autres contextes que des projets purement Eclipse. Des entreprises comme Cloudsmith, EclipseSource, ou Anyware Technologies développent d’ores et déjà des outils basés sur p2 et IBM, entre autres, travaille activement à l’amélioration du noyau p2, ainsi qu’à la définition d’une véritable API.

L’adoption massive d’OSGi dans de nombreux environnements (technologies de runtime telles qu’Equinox ou RAP, serveurs d’applications comme Websphere ou Glassfish…) positionne p2 comme la solution la plus pertinente pour déployer des applications basées sur Eclipse, mais également toutes sortes d’applications scalables. En effet, dès qu’il s’agit de garantir une disponibilité importante des applications, il est indispensable de pouvoir installer ou mettre à jour des modules (parfois à distance) sans avoir à arrêter le système en cours d’utilisation.

Parce qu’il n’y a aucune alternative réelle pour des déploiements industriels —avez-vous déjà essayé d’utiliser Java Web Start pour installer autre chose qu’une application RCP basique? —, p2 s’imposera vraisemblablement comme la technologie standard de déploiement pour des systèmes hétérogènes.

Si le travail de certains contributeurs ou committers vous a particulièrement impressionnés, si des membres de la communauté font selon vous un travail d’évangélisation et de promotion d’Eclipse qui mérite d’être cité, alors n’hésitez pas à aller vous exprimez sur les bugs correspondants du bugzilla Eclipse!

Pour faire court, si vous avez un JDK 1.6 ou supérieur, il ne vous faudra que quelques secondes pour obtenir un état de la pile, puisqu’il suffit d’exécuter :

• jps, afin d’obtenir le PID de la JVM qui vous intéresse
• jstack <pid>, pour obtenir le dump sur la sortie standard

Avec une version de JDK plus ancienne, il faut avoir lancé la JVM (de Sun…) avec l’option -Dcom.sun.management.jmxremote. Cela permet de s’y connecter par la suite avec l’outil jconsole. Bien qu’assez peu contraignante, cette pratique a tout de même l’inconvénient d’obliger à savoir à l’avance que l’application va tomber dans un deadlock, ce qui n’est pas toujours le cas…

Si vous êtes sous Linux, vous avez gagné puisque quelle que soit votre version de Java, un kill -3 <pid_JVM> fonctionnera à coup sûr !

Le wiki détaille d’autres procédures, et notamment comment s’y prendre si l’on veut obtenir le dump d’une application à distance.

Attention, ces entrepôts ne sont pas ceux de Ganymede et de Galileo, ils contiennent simplement le SDK Eclipse !

uDig propose une application Eclipse RCP permettant la visualisation et l’édition d’un grand nombre de formats de données géospatiales (fichiers shapefile, GeoTIFF, services web WFS et WMS, bases Oracle Spatial, PostGIS, etc.) par des utilisateurs pas nécessairement familiers de l’outil informatique. En effet, un gros effort est porté sur l’ergonomie de l’outil, ainsi que sur son internationalisation (italien, français, espagnol, coréen, … basque !, …).

Pour les curieux, un peu plus d’infos sur cette nouvelle release ici :

• http://udig-news.blogspot.com/2008/10/udig-110-released.html

Pour télécharger (Windows, MacOSX & Linux), c’est par là-bas :

• http://udig.refractions.net/download/

Les sessions de formation sont organisées du 3 novembre au 13 décembre.

Les thématiques abordées durant ces classes sont Eclipse RCP (Basic et Advanced), Eclipse Equinox et les technologies de modélisation Eclipse.

Une description complète de toutes les sessions de formation (thèmes, dates, tarifications) est maintenant disponible. Les participants qui s’inscriront avant le 30 Septembre bénéficieront d’une remise de 5% sur le tarif de la formation.

Les compagnies membres de la fondation Eclipse qui participent aux Eclipse Training Series sont les suivantes : ANCIT Consulting, Anyware Technologies, AvanSoft (Eclipse University), Chris Aniszczyk, Gerhardt Informatics, Industrial TSI, Innoopract, itemis, Jeff McAffer, Obeo, The RCP Company, Scott Lewis, Soyatec et Weigle Wilczek.

Vous le savez peut-être, mais l’apport majeur de cette nouvelle version du framework Google de développement d’applications Web est le support de Java 5 : generics, boucles « for each », etc.

Même si certaines APIs peuvent vous manquer (impossible de faire de l’introspection par exemple ), l’émulation de la JRE est particulièrement complète et d’une utilisation tout à fait transparente.
La compatibilité est d’ailleurs telle que l’on peut tout à fait faire tourner le noyau d’EMF (oui oui !) sur GWT.

Parmi les autres nouveautés, il faut noter :

• amélioration des performances (tant au niveau de la compilation que de l’exécution),
• mécanisme de styling simplifié
• support du BiDi (inversion de l’IHM de droite à gauche pour des langues comme l’arabe)
• couche d’interaction Javascript, pour accéder en Java à des librairies Javascript legacy

De plus amples information sur le blog officiel.

[sourcecode language='java']
PlatformUI.getWorkbench().
getBrowserSupport().
createBrowser(« myId »).
openURL(url); [/sourcecode]

myId étant un identifiant unique qui permet, éventuellement, de réutiliser le même navigateur pour ouvrir d’autres pages.

NB : il existe une version de la méthode createBrowser() qui prend en paramètre un style, permettant de préciser si l’on veut afficher ou non la barre d’URL, la barre de navigation, etc.

J’essaierai de préciser dans les jours à venir quelques notions clés de p2 comme celles-ci ; mais en attendant, vous pouvez d’ores et déjà —coucou David !— réaliser un miroir de l’entrepôt Ganymede, et le partager avec vos collègues !
D’ailleurs, cela me fait penser qu’il faudrait que je vérifie si celui que j’ai fait à Anyware est bien d’équerre…

Le miroir de l’entrepôt d’artéfacts (i.e. les binaires des plug-ins et des features) se réalise de la façon suivante :

[sourcecode language='java']./eclipse -nosplash
-application org.eclipse.equinox.p2.artifact.repository.mirrorApplication
-source http://download.eclipse.org/releases/ganymede
-destination file:/home/benjamin/miroirArtefactsGanymede[/sourcecode]

Même principe pour celui de métadonnées (basiquement, ce sont les descriptions des dépendances entre chaque élément de l’entrepôt)

[sourcecode language='java']./eclipse -nosplash
-application org.eclipse.equinox.p2.metadata.repository.mirrorApplication
-source http://download.eclipse.org/releases/ganymede
-destination file:/home/benjamin/miroirMetadonneesGanymede[/sourcecode]

Nota : Il n’est à l’heure actuelle pas possible de descendre dans le même dossier local les deux entrepôts, mais vous pouvez tout à faire la manip’ manuellement. Il suffit de recopier le fichier content.xml de l’entrepôt de métadonnées à côté du fichier artifacts.xml de celui d’artéfacts, et le tour sera joué !

Nota2 : Attention, le mirroring des artéfacts est très long (plusieurs heures). En effet, on demande bien à ne répliquer qu’un et un seul miroir, et on ne peut donc pas bénéficier du téléchargement simultanés de plusieurs artéfacts depuis plusieurs miroirs (parfois très rapides) comme cela peut se faire dans l’utilisation habituelle de p2…

[sourcecode language='java']/**
* @author ${user}
*
*/[/sourcecode]

Vous aurez sûrement remarqué que ${user} est remplacé par le login que vous utilisez dans votre OS, et ce n’est pas toujours ce que l’on veut.

Ainsi,  pour employer un nom d’utilisateur plus parlant que votre simple login, il vous suffit de passer la propriété user.name à votre Eclipse, afin de surcharger la valeur que Java lui attribue par défaut.
Ce qui donne, par exemple (vous pouvez bien sûr, et c’est même conseillé, faire cela en modifiant directement le fichier eclipse.ini):

[sourcecode language='java']eclipse.exe -vmargs -Duser.name= »Benjamin Cabé »[/sourcecode]

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…