Pour ouvrir une URL (depuis un widget SWT “Link”, par exemple) dans le navigateur Web interne d’Eclipse, il suffit de faire ceci :
PlatformUI.getWorkbench().
getBrowserSupport().
createBrowser("myId").
openURL(url);
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.
Une des fonctionnalités apportées par p2 est de pouvoir facilement créer des miroirs d’entrepôts de métadonnées et d’artefacts.
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 :
./eclipse -nosplash -application org.eclipse.equinox.p2.artifact.repository.mirrorApplication -source http://download.eclipse.org/releases/ganymede -destination file:/home/benjamin/miroirArtefactsGanymede
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)
./eclipse -nosplash -application org.eclipse.equinox.p2.metadata.repository.mirrorApplication -source http://download.eclipse.org/releases/ganymede -destination file:/home/benjamin/miroirMetadonneesGanymede
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…
Lorsque vous créez une nouvelle classe Java, Eclipse utilise par défaut le template de code suivant pour générer sa Javadoc :
/**
* @author ${user}
*
*/
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):
eclipse.exe -vmargs -Duser.name="Benjamin Cabé"
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…
Le build d’intégration 3.4 de vendredi a, comme prévu —bien qu’avec un peu de retard−, été taggé “RC1“.
Vous pouvez le télécharger à l’adresse suivante : http://download.eclipse.org/eclipse/downloads/drops/S-3.4RC1-200805161333/index.php.
La liste des bugs corrigés (pour les projets qui la tiennent à jour en tout cas…) est ici.
Voici le petit bout de code, très simple, qui permet de récupérer la version d’un plug-in.
Activator.getDefault().
getBundle().getHeaders().
get(org.osgi.framework.Constants.BUNDLE_VERSION) ;
Pour manipuler de manière un peu plus poussée ce numéro de version, la méthode org.osgi.framework.Version#parseVersion(String) est votre amie.
Vous pourrez dès lors, sur l’objet Version que vous récupérerez, comparer proprement des versions entre elles, récupérer les différents composants de la version (major, minor, micro, qualifier), etc.
Bien sûr, vous vous en doutez, tous les autres en-têtes du manifeste de votre plug-in sont récupérable selon le même principe (Bundle-Copyright, Bundle-Vendor, …)
Ça y est, Eclipse 3.4 est à nos portes puisque le milestone qui sort aujourd’hui est le 7ème du nom ; ce qui, dans le cycle de développement Eclipse, veut dire que toutes les nouvelles fonctionnalités ont été implémentées (feature complete) !
Les prochaines versions livrées seront des releases candidates, au nombre de quatre d’ici fin juin, et n’apporteront donc que des corrections de bugs.
Voici comme à chaque fois les nouveautés à noter, sachant que, pour une M7, on est plutôt gâtés !
Le New & Noteworthy complet est ici !
Et pour le téléchargement, c’est par là !