Categories
Eclipse

Changer la variable ${user}

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é"
Categories
Eclipse

OSGi en bref : La directive singleton

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…

Categories
Eclipse

DemoCamp Toulouse: tapas & démos !

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 :

  • Ganymede (vous voyez à peu près de quoi il s’agit, non ?),
  • Ecore Tools (le-diagrammeur-Ecore-de-la-bombe©)
  • Actidiag (une application RCP de diagnostic automobile)
  • …et tout un tas d’autres petites démos plus informelles.

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…! 🙂