Categories
Eclipse

Mirroring p2

MiroirUne 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…

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…