Eclipse : développement de plug-ins

Développement de clients
riches : Plateforme Eclipse
Mickaël BARON - 2008 (Rev. Avril 2009)
mailto:[email protected] ou mailto:[email protected]
@mickaelbaron
Chapitre 3 : Conception de plug-ins
Introduction à la conception de plug-ins

View Slide

2
Intro. Conc. Plug-in - M. Baron - Page
keulkeul.blogspot.com @mickaelbaron
Creative Commons
Contrat Paternité
Partage des Conditions Initiales à l'Identique
2.0 France
http://creativecommons.org/licenses/by-sa/2.0/fr
Licence

View Slide

3
Organisation du cours sur la conception de plug-ins
Eclipse
OSGi et Eclipse : généralités sur OSGi
Tutoriel de conception : création d’un plug-in
Fichiers de configuration : paramétrer un plug-in
Activator : information sur le plug-in
Platform : information sur l’environnement
Tous les exemples du cours
sont disponibles directement à l’adresse
mbaron.developpez.com/eclipse/introplugin

View Slide

4
Conception de plug-in Eclipse : généralités
Ce support de cours s’intéresse uniquement aux aspects liés
à la conception de plug-ins Eclipse
La conception d’applications Eclipse RCP sera vue dans une
autre partie de ce chapitre et nous étudierons
La classe Application
Perpsective, View, Editor
Product pour générer une application Eclipse RCP
Pour simplifier, la différence entre plug-in et Eclipse RCP est
qu’une application Eclipse RCP est une version stand-alone
d’un plug-in
A l’inverse, un plug-in ne peut être exécuté seul, il faut lui
associer obligatoirement une application Eclipse
Un glossaire de tous les acronymes et concepts est proposé
à la fin de ce support de cours

View Slide

5
Conception de plug-in Eclipse : déroulement du cours
Pédagogie du cours
Présentation des concepts
Illustration avec de nombreux exemples qui sont disponibles à
l’adresse mbaron.developpez.com/eclipse/introplugin
Des bulles d’aide tout au long du cours
Logiciels utilisés
Eclipse 3.3 Europa
Pré-requis
Connaissance de Java
Principes de base concernant la boite à outils SWT
Remerciements
Developpez.com : Néo Kimz, Jawher Moussa, Baptiste Witch
Benjamin Cabé
Ceci est une alerte
Ceci est une astuce

View Slide

6
Introduction à la conception de plug-ins : ressources …
Des articles sur le sujet OSGi et Eclipse
www.ibm.com/developerworks/library/os-ecl-osgi
t-templier.developpez.com/tutoriel/java/osgi/osgi1
www.javaworld.com/javaworld/jw-03-2008/jw-03-osgi1.html?page=1
neilbartlett.name/blog/osgibook
Des articles sur une introduction à la conception de plug-ins
www.eclipsetotale.com/articles/Developpement_de_plugins_Eclipse_partie1.html
wiki.improve.fr/wiki/moni/articles/thirdpartylib
www.ibm.com/developerworks/library/os-eclipse-plugindev1
Des livres
Eclipse – Building Commercial-Quality Plug-ins, 2004 - ISBN : 0-321-22847-2
Eclipse – Rich Client Platform, 2005 – ISBN : 0-321-33461-2

View Slide

7
OSGi : Open Service Gateway Initiative
La plateforme Eclipse repose en partie sur la spécification
OSGi qui est l’acronyme de Open Service Gateway Initiative
La spécification peut être trouvée à l’adresse suivante
www.osgi.org/Specifications/HomePage
Pour synthétiser, la spécification OSGi tente d’adresser deux
types de problématiques
Programmation orientée composant
Architecture orientée service (composants exposent et importent des
services)

View Slide

8
Dans l’architecture OSGi le concept de composant est mis en
œuvre par l’intermédiaire de Bundles
Gestion des bundles (module)
Gestion des différents chargeurs de classes
Gestion des versions des dépendances
Un chargeur de classes par bundle
Cycle de vie des bundles (life cycle)
Cycle de vie du composant lors de son entrée dans le conteneur OSGi
Cycle de vie du composant lors de son utilisation
Services exposés par les bundles (service)
Gestion des services définis dans des interfaces Java

View Slide

9
Différentes implémentations de la spécification OSGi
OSCAR : oscar.objectweb.org
Felix : felix.apache.org
KnopflerFish 2 : www.knopflerflish.org
Eclipse (celle que nous allons étudier)
Pour une vue d’ensemble de toutes les implémentations
OSGi : www.osgi.org/Markets/HomePage

View Slide

10
Un bundle est décrit dans un fichier Jar
Les informations de déploiement sont indiquées dans le
fichier MANIFEST.MF (informations spécifiques à OSGi)
Interactions entre Bundles
Mise à disposition de packages (préciser dans MANIFEST.MF quels
sont les packages à exporter)
Importation de packages (quels sont les packages issus d’autres
bundles à utiliser)

View Slide

11
OSGi et Eclipse
Dans l’implémentation fournie par Eclipse, un bundle corres-
pond à un plug-in
Eclipse a adopté la spécification OSGi depuis la version 3.0
Eclipse ne repose pas complètement sur la spécification
OSGi pour effectuer l’interaction entre les plug-ins
La notion de registres d’extension qui existe depuis le début
de la plateforme permet également de communiquer entre
plug-ins
Dans la suite du cours nous montrons comment les registres
d’extension et les services OSGi sont utilisés
Une comparaison peut être trouvée à l’adresse suivante
www.eclipsezone.com/articles/extensions-vs-services/

View Slide

12
Conception du plug-in « plug-hype »
Nous décrivons dans cette partie la conception d’un plug-in
via l’environnement Eclipse
La démarche est de présenter chaque écran de l’assistant
fourni avec Eclipse pour construire ce plug-in
Nous survolerons également les fichiers générés sachant
qu’ils seront tous détaillés tout au long de ce chapitre
Nous montrerons également les différentes possibilités
offertes par la plateforme Eclipse pour tester ce plug-in
Le plug-in présenté a comme objectif d’afficher une vue
contenant un TableViewer et un label qui affiche « Ceci est
un plug-hype ! »
Pré-requis : un environnement Eclipse avec le module PDE
installé (Plugin Development Environment)

View Slide

13
Tutoriel « plug-hype » : Select a wizard
Sélectionner l’assistant
de création de projet
de plug-in
Sélectionner à partir du menu Eclipse l’action File -> New ->
Project pour ouvrir l’assistant de création de projet
Le groupe « Plug-in
Development » fournit
un ensemble
d’assistants lié à la
conception de plug-in
Rien n’interdit le développement de
plug-in « à la mano », cependant ça
peut être fastidieux …

View Slide

14
Tutoriel « plug-hype » : Plug-in Project
Saisir un nom de
projet lié au
plug-in à créer
Possibilité de modifier
l’emplacement des
fichiers du plug-in
(par défaut celui du
workspace courant)
Choisir le nom des
répertoires sources
et binaires
Choix de la
plateforme cible …
Soit le développement
d’un plug-in Eclipse
(en choisissant la
version de la
distribution)
Soit le développement d’un
bundle OSGi (en choisissant le
type d’implémentation OSGi)

View Slide

15
Tutoriel « plug-hype » : Plug-in Content
Cette page permet de paramétrer le plug-in en cours de
développement
Définition d’un ID qui
permettra d’identifier ce
plug-in parmi les autres
Précise le numéro
de version qui
pourra être utilisé
pour le versioning
lors d’une mise à
jour
Nom du plug-in
Nom de fournisseur
Précise si un Activator
doit être généré ou pas
Nom de l’Activator
Précise si le plug-in
propose ou pas une
IHM
Précise si le plug-in
est autonome ou pas

View Slide

16
Tutoriel « plug-hype » : Select Template
Des templates de génération sont disponibles selon les
options fournies précédemment
Utiliser ou pas les
templates de
création
Des templates
spécifiques qui
embarquent des
IHM
Une aide
contextuelle qui
fournie des
informations sur le
template et les
extensions utilisées
Cette option permet
de sélectionner
plusieurs templates de
génération

View Slide

17
Tutoriel « plug-hype » : Plug-in options
Le nom de la classe
pour la vue à créer
Selon le type de plug-in des options supplémentaires sont à
renseigner
L’ID de la catégorie
qui servira de
regroupement pour
cette vue
Le nom de la
catégorie qui servira
de regroupement
Le nom de la vue

View Slide

18
Tutoriel « plug-hype » : Plug-in options
Différentes options liées à la vue peuvent être précisées
Ajout du support du
double clique sur la vue
Ajout du support du tri
dans le composant
TableViewer

View Slide

19
Tutoriel « plug-hype » : vue rapide sur PDE
L’outil PDE (Plugin Development Environment) fournit entre
autre une vue pour configurer les plug-ins
Certaines
informations saisies
lors de l’assistant sont
disponibles en
édition
Nous détaillerons
chaque écran lors
de la partie fichiers
de configuration
La vue du PDE
structure les
informations à
manipuler par onglet
Toutes les modifications apportées dans la vue
impactent les fichiers de configuration et vice et versa

View Slide

20
Tutoriel « plug-hype » : répertoires et fichiers générés
Un plug-in contient un ensemble de fichiers qui sont
positionnés suivant une logique commune
MANIFEST.MF
Informations générales et
dépendances entre plug-in
plugin.xml
Informations liées aux
extensions et aux
points d’extension
build.properties
Informations liées au
déploiement du plug-in
Activator.java
Classe qui gère le cycle
de vie du plug-in
PlugHype.java
La classe qui définit la vue
du plug-in

View Slide

21
Tutoriel « plug-hype » : exécuter dans Eclipse
Un plug-in peut être vu comme une brique d’une application
et ne peut fonctionner seul
Pour tester un plug-in, il faut l’associer à une application de
type Eclipse
Une application Eclipse est un regroupement de plug-ins
dont le nombre varie selon les fonctionnalités désirées
Dans notre exemple, le plug-in a tester fournit simplement
une vue dont les dépendances avec les autres plug-ins sont
limités
De manière générale pour tester nos plug-ins nous utiliserons
une application Eclipse basée sur une version minimale de
l’IDE d’Eclipse (voir transparents suivants)

View Slide

22
Sélectionner à partir du menu Eclipse l’action Run -> Open
Run Dialog …
Ou à partir de la barre d’actions

View Slide

23
Cette page fournit un gestionnaire de configurations pour
des applications Eclipse
Création d’une
nouvelle
configuration
d’une application
Eclipse
Liste des différentes
configurations
d’exécution

View Slide

24
Cet onglet fournit des indications sur l’application Eclipse à
exécuter
Le répertoire Workspace
indique où seront stockés les
fichiers liés au contexte
d’exécution
L’option « Clear » permet
d’effectuer un nettoyage au
niveau du Workspace
Choix de l’application à
exécuter pour tester le plug-in
« plug-hype ». Dans notre cas
il s’agit d’une version allégée
de l’IDE Eclipse
L’option Run an application
sera choisie quand nous
développerons des
applications Eclipse RCP

View Slide

25
Cet onglet fournit des indications sur les plug-ins qui seront
utilisés lors de l’exécution de l’application Eclipse
Le plug-in
« plug-hype » est
ajouté dans
l’application Eclipse
Ce nœud fournit
tous les plug-ins du
workspace
Ce nœud contient
tous les plug-ins de
la plateforme
Eclipse (ceux
installés dans le
répertoire plugins)
Tous les
plug-ins peuvent
être ajoutés
automatiquement
via l’action Add
Required Plug-ins
Seuls les plug-ins
« vitaux » de la
version allégée de
l’IDE d’Eclipse doivent
être ajoutés
Il ne reste plus
qu’à lancer
l’exécution

View Slide

26
Cet onglet autorise l’enregistrement du fichier de configura-
tion d’exécution
Sélectionner l’option
« Shared file »
Choisir un
répertoire où
sauvegarder
le fichier de
configuration
d’exécution
Après validation un
fichier de
configuration
d’exécution est créé

View Slide

27
Fichier de configuration d’exécution contenant toutes les
informations pour exécuter une application Eclipse
Si un fichier de configuration
d’exécution est présent, la
configuration est automatiquement
présentée dans le gestionnaire de
configuration
Informations
relatives à la
configuration
d’exécution

View Slide

28
Le regroupement Sample
Category contient la vue
Plug-Hype
Cette vue est fournie par
le plug-in Plug-Hype
Version allégée de l’IDE
d’Eclipse
L’ouverture de la fenêtre qui
regroupe toutes les vues est
obtenue par l’action Window ->
Show View -> Other …
Possibilité d’ajouter
une vue dans un
regroupement déjà
existant

View Slide

29
Structure d’un plug-in : généralités
Dans la suite de cette partie, nous présentons la syntaxe
des fichiers de configuration d’un plug-in
L’objectif est d’en ressortir les principales options utilisées
par un plug-in
Cette présentation sera réalisée sur la base des fichiers de
configuration et des interfaces associées fournies par PDE
Trois fichiers de configuration
MANISFEST.MF : informations générales concernant le fonction-
nement d’un plug-in et les différentes dépendances entre plug-ins
plugin.xml : informations liées aux extensions et points d’extension
utilisés et fournis par un plug-in
build.properties : informations liées au déploiement du plug-in

View Slide

30
Structure d’un plug-in : répertoires et fichiers
Un plug-in possède une hiérarchie de répertoires et de
fichiers
src
plugin.xml
Plug-in
bin
icons
META-INF
build.properties
MANIFEST.MF Les informations générales d’un
plug-in et ses dépendances
avec les autres plug-ins
Icônes et images
exploitées par le plug-in
Byte codes du plug-in
Sources Java du plug-in
Informations liées aux extensions et points
d’extension utilisées par ce plug-in
Informations liées au déploiement
Autres fichiers
supplémentaires
Racine d’un
plug-in
lib
*.jar
Des bibliothèques dans
des archives Jar

View Slide

31
Structure d’un plug-in : MANIFEST.MF
Le fichier de configuration MANIFEST.MF décrit le fonction-
nement d’un plug-in dont la spécification est fournie en
partie par OSGi
informations générales (nom, auteur, version, …)
informations de dépendances avec les autres plug-ins
Ce fichier existe depuis longtemps dans le monde Java pour
décrire une archive Jar
Il est possible de mixer les informations liées à l’archive
Jar avec les informations liées au plug-in sous la condition
que ces dernières soient placées en seconde position
Nous présentons dans la suite les principales entrées utiles
pour le développeur de plug-in Eclipse
Une description détaillée de toutes les entrées est disponible
dans la spécification OSGi framework core

View Slide

32
Structure d’un plug-in : MANIFEST.MF
Partie spécifique
à l’archive Jar
Partie spécifique aux
informations du plug-in
MANIFEST.MF du projet
plughype
Généralement l’édition se fait par les
vues fournies par PDE. Toutefois
certaines options ne sont pas
éditables via les vues PDE
Des entrées
définies par la
spécification
OSGi
Si vous éditez directement le fichier
MANIFEST.MF, ne laissez pas de ligne
vide entre les options et laissez
toujours une ligne vide à la fin

View Slide

33
MANIFEST.MF : informations générales
Bundle-ManifestVersion : précise la spécification que doit
suivre ce plug-in (ex : 2 pour la version 4 d’OSGi)
Bundle-Name : nom du plug-in désignant l’objectif du
plug-in (ex : Plughype Plug-in)
Bundle-Vendor : nom de l’organisme ou auteur qui a
développé le plug-in (ex : Mickael BARON)
Bundle-Description : description rapide de l’objectif de ce
plug-in (ex : ce plug-in décrit une vue qui affiche …)
Bundle-Copyright : copyright de ce plug-in
Bundle-RequiredExecutionEnvironment : liste des
environnement d’exécution (J2SE 1.3 par exemple) obliga-
toires pour utiliser ce plug-in (ex : JavaSE-1.6)

View Slide

34
Bundle-SymbolicName : identifiant unique pouvant être
suivi de l’option singleton (booléen)
singleton : si true une seule version de ce plug-in est réalisée, si false
plusieurs versions
Ex : Bundle-SymbolicName: eclipse.plugin.plughype; singleton:=true
Bundle-Activator : nom de la classe utilisée pour démarrer
et arrêter le plug-in (ex : eclipse.plugin.plughype.Activator)
Bundle-Version : précise la version du plug-in construite à
partir de trois numériques (major.minor.micro) et optionnel-
lement une chaîne pour la qualification (ex : 1.0.0.build=34)
Eclipse-PlatformFilter : propre à Eclipse, information
permettant de contraindre l’utilisation d’un plug-in au niveau
d’une plateforme cible (Windows, MAC OS X ou Linux)

View Slide

35
Bundle-SymbolicName
Bundle-Version
Bundle-Name
Vue du PDE relatif aux informations générales d’un plug-in
Bundle-Vendor
Bundle-Activator
Bundle-RequiredExecutationEnvironment
Informations générales
placées dans l’onglet
Overview
Eclipse-PlatformFilter
(information détaillée dans la
partie Fragment & Feature)

View Slide

36
Certaines informations d’un plug-in sont utilisées au niveau
de la vue qui affiche la liste complète des plug-ins
Boîte à propos accessible à partir
de l’action About Eclipse SDK
Affiche quelques informations
générales des plug-ins installées

View Slide

37
MANIFEST.MF : informations de dépendance
Une application Eclipse est composée d’un ensemble de
plug-ins où chaque plug-in peut exploiter des classes
fournies par d’autres plug-ins
Inversement un plug-in peut fournir des classes que d’autres
plug-ins pourront exploiter
Le développement d’une application Eclipse est par
conséquent modulaire
Un plug-in est réutilisable
Le développement d’un plug-in est unitaire
Nous présentons dans la suite les dépendances entre plug-in
via deux plug-ins

View Slide

38
L’exemple présenté dans la suite est basé sur deux plug-ins
dont l’objectif est de sauvegarder et charger le contenu d’un
formulaire
Le plug-in DependenciesExample fournit une vue avec
deux champs de texte
Le plug-in ExportExample fournit un modèle de la vue et
exploite la librairie XStream pour sérialiser/désérialiser le
contenu du modèle
Le plug-in ExportExample expose le package contenant
les classes servant à communiquer avec le modèle de la vue
Le plug-in DependenciesExample à une relation de
dépendance avec ExportExample

View Slide

39
Formalismes graphiques employés pour modéliser les inter-
connexions entre plug-ins
Nom du Plug-in
Les points d’extension
fournis par le plug-in
Point 2
Point 1
Ext 1
Ext 2
Package Exp 2
Package Exp 1
Package Imp 1
Package Imp 2
Les extensions
associées à un autre
plug-in
Les packages, ou de
manière plus fine les
méthodes utilisées par
ce plug-in
Les extensions et les points
d’extension seront détaillés dans la
prochaine partie de ce chapitre
Le nom du plug-in
lib.jar
Singleton = true, …
Les packages, ou de
manière plus fine les
méthodes exportées
par ce plug-in
Différentes options utiles à
la compréhension du
fonctionnement du plug-in

View Slide

40
Schéma de dépendances de l’exemple
DependenciesExample
org.eclipse.ui
views
Perspective ext. …
…
…
…
org.eclipse.core.runtime
…
…
…
De nombreuses
dépendances vers des
plug-ins « bas niveaux »
ExportExample
Le plug-in
ExportExample
met à disposition un
package contenant
deux classes
Le plug-in
core.runtime est le
plug-in indispensable
lors de toute création
de nouveau plug-in
eclipse.plugin.exportexample
Le plug-in
DependenciesExample
est associé à deux points
d’extension fournis par le
plug-in org.eclipse.ui
Le plug-in
DependenciesExample
dépend de trois plug-ins
xstream.jar
Package à exporter

View Slide

41
Un plug-in doit inclure d’autres plug-ins à partir du moment
les packages exportés par les autres plug-ins sont utilisés par ce
plug-in
le plug-in définit des extensions à partir de points d’extension fournis
par les autres plug-ins
Require-Bundle: liste des plug-ins à inclure. Les plug-ins
sont identifiés par leur nom symbolique (valeur définie par la
clé Bundle-SymbolicName)
Exemple
Require-Bundle: org.eclipse.ui, org.eclipse.core.runtime,
eclipse.plugin.ExportExample
MANIFEST.MF du projet DependenciesExample
Trois plug-ins sont requis pour les opérations du
plug-in DependenciesExample

View Slide

42
L’information Require-Bundle propose différentes options
visibility
si valeur private (par défaut), tous les packages exportés par le
plug-in requis ne sont visibles qu’au niveau du plug-in qui effectue la
dépendance
si valeur reexport, tous les packages exportés par le plug-in requis
sont diffusés à tous les niveaux supérieurs
Exemple : si le plug-in A requiert le plug-in B, et que le plug-in B
requiert le plug-in C dont la visibilité est reexport, alors le plug-in A
aura accès au contenu de C comme si A avait requis le plug-in C
resolution
si valeur mandatory (par défaut), le plug-in requis doit exister
si valeur optional, le plug-in requis n’est pas utile au fonctionnement
du plug-in qui demande la dépendance

View Slide

43
bundle-version
Cette option facultative permet de restreindre la dépendance d’un
plug-in en fonction de son numéro de version
La restriction peut s’effectuer soit par un numéro de version exacte
soit par un intervalle entre une version minimum et maximum
Syntaxe pour la définition d’un écart de version
[min, max) : où min correspond à la version minimum et max la
version maximum
[ = min est inclue dans l’écart, ( = min n’est pas inclue dans l’écart
] = max est inclue dans l’écart, ( = max n’est pas inclue dans l’écart
Exemples
[3.0.0, 3.1.0) nécessite un plug-in estampillé 3.0.x
[3.3.0, 4.0.0) nécessite un plug-in estampillé 3.3.x
3.3.0 nécessite un plug-in estampillé 3.3.0

View Slide

44
DependenciesExample
Dépendances placées dans
l’onglet Dependencies
Liste des plug-ins
requis
Ajouter une dépendance
vers un plug-in
Supprimer une dépendance
vers un plug-in déjà requis
Propriétés
concernant la
dépendance
Définition des contraintes (visibility,
resolution et bundle-version)

View Slide

45
MANIFEST.MF : informations d’exportation
Export-Package : liste l’ensemble de packages qui seront
exportés par ce plug-in
Les packages peuvent contenir les classes qui seront par
conséquent implicitement exportés
Les sous packages ne sont pas exportés, il faut selon les
besoins les ajouter dans la liste des packages à exporter
Les principales options disponibles
x-friends : spécifie les plug-ins autorisés à importer un package
donné
Exemple
Export-Package: eclipse.plugin.exportexample;
x-friends:="eclipse.plugin.DependenciesExample"
MANIFEST.MF du projet ExportExample
Le package exportexample est exporté et seul le
plug-in DependenciesExample peut l’importer

View Slide

46
MANIFEST.MF : informations d’exportation
Exportation de packages placée
dans l’onglet Runtime
Le package
eclipse.plugin.exportexample
est exporté
Possibilité de choisir
les plug-ins
autorisés à utiliser le
package exporté
Le plug-in
DependenciesExample
est le seul plug-in à
utiliser le package
exportexample

View Slide

47
MANIFEST.MF : exemple (dépendance + exportation)
Exemple : plug-in ExportExample
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: ExportExample Plug-in
Bundle-SymbolicName: eclipse.plugin.ExportExample
Bundle-Version: 1.0.0
Bundle-Activator: eclipse.plugin.exportexample.Activator
Bundle-Vendor: Mickael BARON
Require-Bundle: org.eclipse.core.runtime
Eclipse-LazyStart: true
Export-Package: eclipse.plugin.exportexample;version="1.0.0";
x-friends:="eclipse.plugin.DependenciesExample"
Bundle-ClassPath: lib/xstream-1.3.jar, .
ExportExample
L’arborescence des
fichiers et répertoires
du plug-in
ExportExample
Seul le package
eclipse.plugin.exportexample est public

View Slide

48
Exemple (suite) : plug-in ExportExample
package eclipse.plugin.exportexample;
public interface ISerializeName {
String getName();
void setName(String pName);
String getDescription();
void setDescription(String pDescription);
void loadFromXML() throws FileNotFoundException;
void saveFromXML() throws FileNotFoundException;
}
public class Activator extends Plugin {
...
public ISerializeName getSerializeInstance() {
return new SerializeName();
}
}
ISerializeName.java du
projet ExportExample
Activator.java du projet
ExportExample
L’objet Activator
fournit une gestion du
cycle de vie du plug-in
Cette interface fournit
les services exposés
par le plug-in
Une méthode sert à créer une
instance de ISerializeName ce qui
permet de cacher l’implémentation

View Slide

49
Exemple (suite) : plug-in ExportExample
package eclipse.plugin.exportexample.internal
public class SerializeName implements ISerializeName {
private String name = "";
private String description = "";
public String getName() {
return name;
}
public void saveFromXML() throws FileNotFoundException {
XStream xstream = new XStream(new DomDriver());
FileOutputStream out = new FileOutputStream("serial.xml");
xstream.toXML(this, out);
}
public void loadFromXML() throws FileNotFoundException {
XStream xstream = new XStream(new DomDriver());
FileInputStream in = new FileInputStream("serial.xml");
SerializeName temp = (SerializeName)xstream.fromXML(in);
this.setName(temp.getName());
this.setDescription(temp.getDescription());
}
public void setName(String pName) {
this.name = pName;
}
public String getDescription() {
return description;
}
public void setDescription(String pDescription) {
this.description = pDescription;
}
}
SerializeName.java du
L’implémentation n’est pas
public
La bibliothèque XStream
permet de sérialiser et dé-
sérialiser le contenu de cet
objet

View Slide

50
Exemple : plug-in DependenciesExample
DependenciesView.java du projet
DependenciesExample
L’action Sauvegarde
appelle le service
saveFromXML() du
plug-in
ExportExample
L’action Chargement
appelle le service
loadFromXML() du
plug-in
ExportExample
Un champ pour la saisie du
Nom
Un champ pour la saisie de
la description

View Slide

51
Exemple (suite) : plug-in DependenciesExample
public class DependenciesView extends ViewPart {
private ISerializeName currentSerializeFactory;
public DependenciesView() {
currentSerializeFactory = Activator.getDefault().getSerializeInstance();
}
public void createPartControl(Composite parent) {
...
myLoadAction.addSelectionListener(new SelectionAdapter() {
public void widgetSelected(SelectionEvent e) {
try {
currentSerializeFactory.loadFromXML();
} catch (FileNotFoundException e1) {
e1.printStackTrace();
}
myNameText.setText(currentSerializeFactory.getName());
myFillText.setText(currentSerializeFactory.getDescription());
}
});
mySaveAction.addSelectionListener(new SelectionAdapter() {
...
}
});
}
public void setFocus() {
}
}
DependenciesView.java du projet
DependenciesExample
Classe ViewPart permet de
définir une vue par extension
Accès à l’instance ISerializeName
par l’intermédiaire de la factory
fournie par le plug-in
ExportExample

View Slide

52
Exemple (suite) : plug-in DependenciesExample
DependenciesExample
Le plug-in ExportExample est ajouté
dans les dépendances de manière à
intégrer la partie modèle dans l’IHM

View Slide

53
Dépendance vers une bibliothèque
Certains plug-ins peuvent avoir besoin de s’appuyer sur des
bibliothèques tierces
Plusieurs approches sont à envisager
1. Intégration de la bibliothèque dans le plug-in qui l’utilise
2. Transformation du JAR externe en plug-in qui deviendra ainsi un
containeur d’un plug-in
3. Création d’un plug-in qui regrouperait toutes les librairies tierces et
qui deviendra ainsi un repository de bibliothèques tierces
Le choix de telle ou telle approche dépend de la fréquence
d’utilisation de la bibliothèque
Nous présenterons chacune de ces approches via notre
exemple et la bibliothèque XStream

View Slide

54
Intégration d’une librairie dans un plug-in
Cette première approche permet d’intégrer les fichiers JAR
des bibliothèques directement dans le plug-in qui les utilise
L’avantage de cette approche est de simplifier l’intégration
d’une bibliothèque
En contrepartie, si la bibliothèque est utilisée dans plusieurs
plug-ins, il faudra dupliquer l’archive de la bibliothèque
Le mode opérateur à réaliser est le suivant
création d’un répertoire lib à la racine du plug-in
copie des fichiers JAR dans le répertoire lib
déclarer les fichiers JAR dans le classpath du plug-in
L’entrée Bundle-ClassPath du fichier MANIFEST.MF est
utilisée pour renseigner toutes les librairies à ajouter dans le
classpath

View Slide

55
Intégration d’une librairie dans un plug-in
Ajout de la bibliothèque
XStream dans le classpath
du plug-in
La bibliothèque est
automatiquement ajoutée
dans les propriétés du projet
L’entrée Bundle-ClassPath contient
toutes les librairies à ajouter dans le
classpath du plug-in ExportExample
N’oubliez de renseigner le répertoire courant
« . » dans l’entrée Bundle-ClassPath
ExportExample

View Slide

56
Transformation d’une librairie en plug-in
La deuxième approche consiste à placer dans un plug-in la
librairie et d’exporter les packages nécessaires
L’avantage est de considérer la librairie comme un plug-in et
par conséquent si un plug-in a besoin d’utiliser la librairie, il
dépendra directement du plug-in contenant la librairie
En contrepartie, il peut être plus fastidieux de mettre à jour
le contenu du plug-in « librairie » quand une nouvelle
version de la librairie est disponible
L’environnement de développement Eclipse fournit un
Wizard permettant d’automatiser la transformation de la
librairie en plug-in
Le mode opérateur à réaliser est le suivant
Utiliser l’assistant de transformation
Ajouter la dépendance vers le plug-in librairie

View Slide

57
Sélectionner à partir du menu Eclipse l’action File -> New ->
Other pour ouvrir la liste des assistants
Choisissez l’assistant Plug-in from
existing JAR archives

View Slide

58
Sélectionner les archives JAR à inclure dans le plug-in
Utiliser le bouton Add External …
pour ajouter une archive JAR à
partir d’un chemin physique
Utiliser le bouton Add … pour
ajouter une archive JAR déjà incluse
dans un plug-in

View Slide

59
Saisir les informations pour créer le plug-in librairie
Le nom du plug-in correspond
généralement au package utilisé
par la bibliothèque
En cochant cette option, les fichiers
seront de la librairie sont extrait de
l’archive JAR

View Slide

60
com.thoughworks.xstream
Tous les packages de la librairie
sont automatiquement exportés,
possibilité d’intervenir
manuellement pour en cacher
certains
Les packages de la librairie sont exportés automatiquement

View Slide

61
Au moment de l’exécution de l’action de désérialisation, un
exception est lancée
La classe SerializeName est
introuvable

View Slide

62
La librairie XStream a besoin de connaître le classpath de la
classe à désérialiser située dans le plug-in ExportExample
Le plug-in ExportExample a déjà une dépendance vers le
plug-in librairie XStream
Eclipse ne recommande pas les dépendances cycliques via le
mécanisme présenté précédemment
Considérons pour la suite deux plug-ins A et B
Si A a un dépendance vers B, B ne peut avoir de dépendance vers A
Toutefois B a besoin d’accéder aux ressources (classes, images) de A
Eclipse fournit un autre mécanisme permettant d’expliciter
cette dépendance en ajoutant des informations spécifiques à
la politique du classloading

View Slide

63
Les informations à ajouter ne peuvent être réalisées via
l’outil PDE, elles doivent être éditées directement dans le
fichier MANIFEST.MF
Dans le MANIFEST.MF du plug-in A préciser que le plug-in B
souhaite accéder à ces ressources
Eclipse-RegisterBuddy: eclipse.plugin.B
Où eclipse.plugin.B désigne l’ID du plug-in B
Dans le MANIFEST.MF du plug-in B préciser la politique du
classloading
Eclipse-BuddyPolicy: registred
Dans le cas des plug-ins librairies, penser à ajouter systéma-
tiquement la politique du classloading à registred
A noter que le plug-in B a connaissance de tous les packages
du plug-in A et pas uniquement ceux exportés

View Slide

64
Modification de la politique de chargement du classloading
du plug-in XStream MANIFEST.MF du projet
com.thoughworks.xstream
ExportExample
Précise que le plug-in xstream
souhaite accéder aux ressources du
plug-in ExportExample
Précise que le plug-in xstream
peut avoir accés à différents
classpath que le sien

View Slide

65
Plug-in repository de librairies
La troisième approche consiste à intégrer dans un même
plug-in toutes les librairies à utiliser
Cela consiste à utiliser la deuxième approche est de
multiplier le nombre de librairies à ajouter
Toutes les librairies seront extraites des archives JAR
Tous les packages seront automatiquement exportés par le
plug-in
Cette approche est à utiliser quand les librairies ont des
intérêts communs et des fonctionnalités équivalents
Essayer de regrouper logiquement les librairies quittes à
créer plusieurs plug-in repository
Une solution est proposée par le projet Orbit qui permet
d’automatiser la gestion des librairies www.eclipsecon/orbit

View Slide

66
Structure d’un plug-in : plugin.xml
Le fichier plugin.xml permet la description des extensions et
des points d’extension d’un plug-in
Un point d’extension décrit un contrat qui stipule la manière
dont des interfaces et des classes d’un plug-in doivent être
utilisées par d’autres plug-ins
Le contrat est décrit au travers d’un schéma XML
Nom du Plug-in
Les points d’extension
fournis par le plug-in
Point 2
Point 1
Ext 1
Ext 2
…
…
…
Les extensions associées à
un autre plug-in
…

View Slide

67
L’extension est la réponse apportée à un point d’extension
Pour tout point d’extension exploité par un plug-in une
extension est obligatoirement réalisée
L’extension devra par conséquent respecter le schéma
imposé par le point d’extension
La notion de registres d’extension est donc un autre moyen
pour communiquer entre plug-ins
La partie suivante
présentera en détail la
notion de points d’extension
et d’extension
Point d’extension défini
par un plug-in
Extension qui
respecte le schéma
du point d’extension

View Slide

68
plugin.xml du projet
DependenciesExample
Création des extensions via
l’onglet Extensions
Création des extensions via l’outil PDE
Un extension est
réalisée via le point
d’extension
org.eclipse.ui.views
Des informations sont à renseigner
pour respecter le contrat fourni par
le point d’extension

View Slide

69
Création des extensions directement via le fichier plugin.xml
Chaque extension
doit respect le
schéma imposé par le
point d’extension
Edition du fichier plugin.xml
via l’onglet plugin.xml
DependenciesExample

View Slide

70
Création des points d’extension via l’outil PDE
Création des points d’extension via
l’onglet Extensions Points
DependenciesExample
Ce plug-in ne fournit pas
de point d’extension

View Slide

71
Structure d’un plug-in : build.properties
Le mécanisme de Build du plug-in est dirigé par le fichier de
configuration build.properties formaté comme un fichier de
properties Java
Ce fichier est généré par l’assistant de création de plug-ins et
contient toutes les informations sur la manière de compiler
les sources pour les transformer en JAR
Les clés importantes du fichier
source. : liste les répertoires sources qui seront compilés
output. : liste les répertoires qui recevront le résultat de la
compilation
bin.includes : liste les fichiers qui seront inclus dans la version
déployée du plug-in

View Slide

72
Faites attention d’inclure
(bin.includes) toutes les ressources
nécessaire au bon fonctionnement
du plug-in (images, dll, …)
Pour chaque librairie du plug-in
indiquer les répertoires sources
à compiler
Dans cet exemple seul les sources du
plug-in sont compilés (noté « . »)
Pour chaque librairie du plug-in
indiquer les répertoires qui
recevront la compilation
Build.properties du
Liste l’ensemble des fichiers qui
seront inclus inclus dans
l’archive de déploiement du
plug-in
Exemple : build.properties du plug-in ExportExample

View Slide

73
Exemple (suite) : build.properties du plug-in ExportExample
bin.includes
sources..

View Slide

74
Déployer les plug-ins
Quand le développement des plug-ins est terminé, les
plug-ins peuvent être déployés
De manière générale, pour chaque plug-in déployé, une
archive JAR est générée
Une fois les fichiers JAR générés, il suffit de copier les
archives dans le répertoire plug-in de la version Eclipse qui
doit accueillir ces nouveaux plug-ins
La génération de la version à déployer s’appuie sur le fichier
de configuration build.properties (voir précédemment)
Dans le cas des applications Eclipse RCP (version standalone
d’un plug-in), nous utiliserons la notion de product pour
générer la version de déploiement
L’environnement Eclipse fournit un assistant pour en générer
une version « prête à l’emploi »

View Slide

75
Sélectionner à partir du menu Eclipse l’action File -> Export
pour ouvrir la liste des assistants liés à l’exportation
Choisir l’assistant
Deployable plug-ins and
fragments

View Slide

76
Choisir les plug-ins à déployer
Le résultat de la génération
sera placé dans un répertoire
Le résultat de la génération
sera placé dans une archive
Différentes options

View Slide

77
Précise si les sources doivent être incluses
Précise si les packages
doivent être archivés dans
des JAR
Remplace les chaînes « .qualifier »
contenues dans build.properties par la
valeur donnée du champ de texte
Génère également une
tâche ANT relatif à cette
tâche d’exportation
Onglet Options
Onglet JAR Signing
Ensemble d’options pour
signer un JAR
Un cours sur la signature des
JARs est disponible à l’adresse
mbaron.developpez.com/jws

View Slide

78
Structure d’un plug-in : Activator
Un plug-in fournit une classe appelée Activator chargée de
gérer le cycle de vie du plug-in lors de son utilisation
gérer les ressources qui doivent être chargées au démarrage
du plug-in
Un objet Activator est un sous type de la classe Plugin
Le nom de la classe est définie par le fichier de configuration
MANIFEST.MF du plug-in au niveau de l’information
Bundle-Activator
Un objet Activator n’est pas obligatoire, un objet de la
plateforme sera alors utilisé par défaut qui ignore les
requêtes liées au cycle de vie
Dans la suite, nous étudierons les méthodes fournit par la
classe Plugin

View Slide

79
Activator : cycle de vie
Le cycle de vie lors de l’utilisation du plug-in est géré par
start(BundleContext context) throws Exception : déclenchée quand le
plug-in est chargé
stop(BundleContext context) throws Exception : déclenchée quand le
plug-in est détruit
La politique de chargement par défaut du plug-in est dite
Lazy-Loading, ce qui signifie que le plug-in est chargé quand
il doit être utilisé (utilisation d’un service par exemple)
Si vous redéfinissez ces méthodes, rappeler obligatoirement
l’implémentation de la super classe
Evitez également d’effectuer dans ces méthodes des traite-
ments couteux (mémoire et rapidité) qui pourraient ralentir
de le démarrage du plug-in

View Slide

80
Pour accéder facilement à l’instance d’un Activator utiliser le
design pattern Singleton
Le design pattern Singleton permet la création d’objets
uniques dont il n’existe qu’une seule instance
Principe général de mise en œuvre d’un Singleton
A la création d’un « singleton » vérifier si il existe déjà une instance
Si elle existe fournir l’instance, si elle n’existe pas création d’une
instance
Lors de la création de la classe Activator par l’outil PDE, une
méthode static est générée automatiquement
public static Activator getDefault() : retourne l’instance unique de
l’objet Activator
La mise en œuvre du singleton est obtenue par l’intermé-
diaire de la méthode start appelée qu’une seule fois

View Slide

81
Nous présentons dans la suite un exemple qui permet de
montrer la politique de chargement via le « LazyLoading »
Un nouveau plug-in appelé LazyLoadingExample fournit une
vue qui fait appel aux services fournit par ExportExample
La vue de LazyLoadingExemple propose trois boutons
Creation : demande une instance de type ISerializeName au plug-in
ExportExample. Il s’agit du premier appel à ExportExample, le plug-in
est donc démarré
Sauvegarde : demande de sauvegarde. Le bouton n’est activé que
si l’action Creation a été effectuée
Chargement : demande de chargement. Le bouton n’est activé que
si l’action Creation a été effectuée
Le plug-in ExportExample a été modifié pour notifier dans la
console le démarrage du plug-in

View Slide

82
Exemple : principe de LazyLoading d’un plug-in
Lors de l’appui sur le bouton Creation,
le plug-in ExportExample est chargé,
les boutons Sauvegarde et Chargement
sont activés et le bouton Creation est
désactivé
Lors de l’appui sur le bouton
Sauvegarde le sérialisation est réalisée

View Slide

83
Exemple (suite) : principe de LazyLoading d’un plug-in
public class Activator extends Plugin {
...
public ISerializeName getSerializeInstance() {
return new SerializeName();
}
public void start(BundleContext context) throws Exception {
super.start(context);
plugin = this;
System.out.println("Le Plug-In ExportExample est chargé");
}
public void stop(BundleContext context) throws Exception {
plugin = null;
super.stop(context);
System.out.println("Le Plug-in ExportExample est arrété");
}
public static Activator getDefault() {
return plugin
}
}
ExportExample
Les méthodes start et stop
ont été décorées d’un
affichage vers la console
pour avertir le démarrage
et l’arrêt du plug-in
Au moment du
démarrage du plug-in
(réalisé une seule fois)
l’instance courante est
stockée
Méthode permettant
d’accéder au singleton
de l’objet Activator

View Slide

84
package eclipse.plugin.lazyloadingexample;
public class LazyLoadingView extends ViewPart {
...
createButton.addSelectionListener(new SelectionAdapter() {
if (!isCreated) {
saveSerialization.setEnabled(true);
loadSerialization.setEnabled(true);
createButton.setEnabled(false);
isCreated = true;
currentSerializeFactory = Activator.getDefault().getSerializeInstance();
}
}
});
...
saveSerialization.addSelectionListener(new SelectionAdapter() {
currentSerializeFactory.setName("LazyLoadingView");
currentSerializeFactory.setDescription("This is a sample message");
try {
currentSerializeFactory.saveFromXML();
} catch (FileNotFoundException e1) { e1.printStackTrace(); }
}
});
saveSerialization.setEnabled(false);
... // Suite dans le prochain transparent
}
}
LazyLoadingView.java du projet
LazyLoadingExample
Activation des boutons
saveSerialization et
loadSerialization puis désactivation
du bouton createButton
Utilisation de la classe Activator
du plug-in ExportExample qui
provoque le démarrage du
plug-in ExportExample

View Slide

85
package eclipse.plugin.lazyloadingexample;
public class LazyLoadingView extends ViewPart {
...
loadSerialization = new Button(parent, SWT.NONE);
loadSerialization.addSelectionListener(new SelectionAdapter() {
try {
currentSerializeFactory.loadFromXML();
} catch (FileNotFoundException e1) {
e1.printStackTrace();
}
System.out.println(currentSerializeFactory.toString());
}
});
loadSerialization.setEnabled(false);
}
}
A la construction les boutons
saveSerialization et
loadSerialization sont désactivés
LazyLoadingView.java du projet
LazyLoadingExample

View Slide

86
Activator : informations sur le Bundle
Possibilité d’accéder aux informations d’un objet Bundle (un
plug-in du point de vue Eclipse)
Bundle getBundle() : retourne le Bundle associé au plug-in
Vous n’aurez généralement pas besoin d’utiliser directement
les méthodes fournies par la classe Bundle
Un objet Bundle fournit les informations suivantes
long getBundleId() : identifiant unique attribué lors de l’installation
dans le conteneur OSGi
int getState() : état du Bundle (UNINSTALLED, INSTALLED,
RESOLVED, STARTING, STOPPING, ACTIVE)
String getSymbolicName() : nom symbolique du Bundle définit par
l’entrée Bundle-SymbolicName
Dictionary getHeaders() : informations de l’en-tête du MANIFEST
Différentes méthodes qui pilotent le cycle de vie du Bundle (start,
stop, uninstall, …)

View Slide

87
Activator : informations sur le Bundle
Exemple : accéder aux informations du Bundle d’un plug-in
public class BundleExample extends ViewPart {
...
Button myBundleInformation = new Button(parent, SWT.NONE);
final Text myText = new Text(parent, SWT.WRAP);
...
myBundleInformation.addSelectionListener(new SelectionAdapter() {
Bundle bundle = Activator.getDefault().getBundle();
long bundleId = bundle.getBundleId();
String bundleState = "";
switch (bundle.getState()) {
case Bundle.INSTALLED:
bundleState = "INSTALLED";
break;
...
}
String bundleSymbolicName = bundle.getSymbolicName();
myText.append("Bundle ID : " + bundleId + "¥n");
myText.append("Etat du bundle : " + bundleState + "¥n");
myText.append("Nom Symbolic : " + bundleSymbolicName + "¥n");
}
});
}
}
BundleExample.java du projet
BundleExample

View Slide

88
Activator : gestion des préférences d’un plug-in
Un Activator est également en charge de gérer implicitement
les préférences du plug-in associé
Lors du démarrage du plug-in ces préférences sont chargées
Lors de l’arrêt du plug-in ces préférences peuvent être sauvegardées
Dans la seconde partie du cours JFace, une API pour les
préférences (IPreferenceStore) a été introduite
Toutefois, la plateforme Eclipse préconise l’utilisation d’une
nouvelle API fondée sur les mêmes principes dans le cadre
du développement de plug-in
Dans le cas du développement d’applications Java avec
uniquement les APIs SWT/JFace l’utilisation de la classe
IPreferenceStore est recommandée (réduction des
dépendances)

View Slide

89
La classe Preferences du package org.eclipse.core.runtime
fournit des méthodes semblables à celles fournit par
la classe IPreferenceStore
boolean getBoolean(String name) … : des accesseurs sur des valeurs
de préférence par l’intermédiaire d’un nom
boolean getDefaultBoolean(String name) … : des accesseurs sur les
valeurs par défaut au travers d’un nom
void setValue(String name, boolean value) : des modifieurs sur les
valeurs au travers d’un nom et d’une valeur
void setDefaultValue(String name, boolean value) : des modifieurs sur
les valeurs par défaut par l’intermédiaire d’un nom et d’une valeur
store(OutputStream, String header) : sauvegarde explicite
load(InputStream) : chargement explicite

View Slide

90
La classe Activator de type Plugin fournit plusieurs méthodes
pour manipuler les préférences
Preferences getPluginPreferences() : accesseur sur le gestionnaire de
préférences du plug-in
savePluginPreferences() : sauvegarde des préférences
Le chargement des préférences du plug-in est implicite, il est
assuré lors de l’appel à la méthode start() du plug-in
La sauvegarde n’est pas automatique et la méthode
savePluginPreferences() doit être appelée

View Slide

91
Les préférences sont persistées dans un sous répertoire du
répertoire workspace du contexte d’exécution
workspace/.metadata/.plugins/org.eclipse.core.runtime/.settings/
où workspace est le répertoire de travail d’une application Eclipse
Le fichier de préférence est construit à partir du nom du
plug-in suivi de l’extension .prefs
Exemple : eclipse.plugin.PreferenceExample.prefs pour un plug-in
dont le nom est eclipse.plugin.PreferenceExample
A noter que le répertoire org.eclipse.core.runtime est choisi
car il gère toutes les préférences de tous les plug-ins d’une
application Eclipse
Si vous procédez à un « Clear » du
workspace avant l’exécution de
l’application Eclipse, toutes les préférences
seront supprimées

View Slide

92
Exemple : gestion des préférences dans un plug-in
Si le bouton Sauvegarde et Afficher
est utilisé, Deux clés sont modifiées
dans les préférences : NAME et
DESCRIPTION
Le fichier
eclipse.plugin.PreferenceExample.prefs contient
les préférences pour le plug-in associé
Les valeurs sont disponibles
pour le prochain
chargement

View Slide

93
Exemple (suite) : gestion des préférences dans un plug-in
public class PreferenceView extends ViewPart {
...
loadPreference.addSelectionListener(new SelectionAdapter() {
loadPreferences();
}
});
savePreference.addSelectionListener(new SelectionAdapter() {
Preferences preferences = Activator.getDefault().getPluginPreferences();
preferences.setValue("NAME", "BARON Mickael");
preferences.setValue("DESCRIPTION", "Ceci est une description donnée vers " +
Long.toString(System.currentTimeMillis()));
Activator.getDefault().savePluginPreferences();
loadPreferences();
}
});
}
private void loadPreferences() {
String name = preferences.getString("NAME");
String description = preferences.getString("DESCRIPTION");
displayPreferences.append(name + " ");
displayPreferences.append(description);
}
}
PreferenceView.java du projet
PreferenceExample
Modifie les préférences et
provoque une sauvegarde

View Slide

94
Dans le cas où le fichier de préférences n’existe pas, il peut
être intéressant de les initialiser avant utilisation
La plateforme Eclipse fournit un point d’extension adapté à
l’initialisation des préférences par défaut
L’initialisation est donc obtenue via l’utilisation du point
d’extension org.eclipse.core.runtime.preferences
L’extension relative à ce point doit contribuer à détailler
l’élément initializer
L’élément initializer requiert l’utilisation d’une classe de type
AbstractPreferenceInitializer
Cette classe fournit une méthode pour initialiser
void initializeDefaultPreferences() : appelée pour initialiser les préfé-
rences par défaut

View Slide

95
Exemple : initialisation des préférences par défaut
PreferenceExample
Pour ajouter une nouvelle extension
à un point d’extension
Le cours suivant fournit des
explications détaillées sur la manière
de manipuler des extensions et des
points d’extension
Onglet Extensions pour définir des
extensions

View Slide

96
Exemple (suite) : initialisation des préférences par défaut
Choisir le point d’extension
org.eclipse.core.runtime.preferences
Une description du point d’extension
est donnée pour expliquer son
objectif
Assistant disponible lors de
l’ajout d’une nouvelle extension

View Slide

97
L’élément initializer requiert
une classe de type
AbstractPreferenceInitializer
PreferenceExample
Onglet Extensions pour
définir des extensions

View Slide

98
package eclipse.plugin.preferenceexample;
public class PreferenceInitializer extends AbstractPreferenceInitializer {
public PreferenceInitializer() {
}
public void initializeDefaultPreferences() {
preferences.setDefault("NAME", "Default John");
preferences.setDefault("DESCRIPTION", "Ceci est un nom par defaut");
}
}
PreferenceInitializer.java du
projet
PreferenceExample
Méthode à redéfinir dont le but est
d’initialiser les préférences par défaut Cette classe fait partie de la
définition de l’extension
Dans le cas où le fichier de
préférences n’existait, les préférences
par défaut sont chargées

View Slide

99
Activator : gestion des Logs
La classe Plugin fournit un mécanisme qui facilite l’accès à
un fichier de logs
Le contenu des logs est localisé par défaut dans le fichier
.log placé dans le répertoire .metadata du workspace
Si le répertoire workspace est à la racine du C, le fichier .log peut
être localisé dans c:\workspace\.metadata\.log
Il s’agit d’un mécanisme propre à Eclipse et rien n’empêche
d’utiliser conjointement une librairie externe comme Log4j
Plugin fournit la méthode
ILog getLog() : accesseur sur l’interface permettant de gérer les logs
L’interface ILog fournit entre autre une méthode
void log(IStatus status) : l’objet Status est logué

View Slide

100
La notion d’objet IStatus a été définie dans le précédent
chapitre concernant les composants additionnels avec JFace
Un objet IStatus est défini par les attributs suivants
id du plugin : id du plugin associé à l’objet Status
une sévérité (CANCEL, ERROR, INFO, OK, MESSAGE)
code : code donné par le plugin
un message : un message qui accompagne le status
une exception : une exception liée au problème (peut être null)
La classe Status est une implémentation par défaut
Status(int severity, String pluginId, int code, String message,
Throwable exception)

View Slide

101
Exemple : utilisation du gestionnaire de Logs d’Eclipse
.log du workspace LogExample
LogView du projet LogExample
Action to log, un log est posté
dans le fichier .log

View Slide

102
Exemple (suite) : utilisation du gestionnaire de Logs d’Eclipse
public class Activator extends AbstractUIPlugin {
...
plugin = this;
this.getLog().log(new Status(IStatus.INFO, PLUGIN_ID, 0, "Le Plug-In LogExample vient de
demarrer", null));
}
public void stop(BundleContext context) throws Exception {
plugin = null;
super.stop(context);
this.getLog().log(new Status(IStatus.INFO, PLUGIN_ID, 0, "Le Plug-In LogExample vient de
s'arreter", null));
}
...
}
LogExample
Lors du démarrage du
plug-in un log est posté
dans le fichier .log

View Slide

103
Exemple (suite) : utilisation du gestionnaire de Logs d’Eclipse
public class LogView extends ViewPart {
public LogView() {
}
parent.setLayout(new FillLayout());
Button myCurrentButton = new Button(parent, SWT.FLAT);
myCurrentButton.addSelectionListener(new SelectionAdapter() {
Activator.getDefault().getLog().log(new Status(IStatus.INFO, Activator.PLUGIN_ID,
0, "Action sur le Bouton a l'instant : " + System.currentTimeMillis(), null));
}
});
myCurrentButton.setText("Action to Log");
}
public void setFocus() {
}
}
LogView.java du projet
LogExample
« Action to log », un log est
posté dans le fichier .log

View Slide

104
Activator : AbstractUIPlugin
Dans le cas où le plug-in emploie des éléments de la couche
graphique, Activator hérite de la classe AbstractUIPlugin
AbstractUIPlugin est une sous classe de la classe Plugin
(étudiée précédemment)
Un objet AbstractUIPlugin fournit des fonctionnalités propres
à la gestion de ressources graphiques
Registre pour les images
Gestion des dialogues
La classe AbstractUIPlugin fournit un second mécanisme de
gestion de préférences basé sur l’API JFace, préférez celle
fournie par la classe Plugin qui est plus récente

View Slide

105
AbstractUIPlugin : ImageRegistry
La classe AbstractUIPlugin fournit un registre pour la gestion
efficaces des images
Par défaut, l’objet ImageRegistry est initialisé au démarrage
du plug-in, si besoin d’une nouvelle initialisation
protected ImageRegistry createImageRegistry() : création d’un nou-
veau registre d’images
L’accès à un objet ImageRegistry est réalisé par
public ImageRegistry getImageRegistry() : retourne le registre des
images pour le plug-in donné
La classe AbstractUIPlugin fournit également une méthode
pour la création d’objets ImageDescriptor
public static ImageDescriptor imageDescriptorFromPlugin(String
pluginId, String imageFilePath) : création d’un ImageDescriptor
Des informations sur ImageRegistry peuvent être trouvées
dans la partie Composants additionnels avec JFace

View Slide

106
Exemple : utilisation de l’ImageRegistry d’un plug-in
public class Activator extends AbstractUIPlugin {
...
public static final String SUPERSTAR = "SUPERSTAR";
plugin = this;
// Put the ImageDescriptors object into the current images registry.
ImageDescriptor superstarID = Activator.getImageDescriptor("icons/superstar.jpg");
this.getImageRegistry().put(SUPERSTAR, superstarID);
}
public static ImageDescriptor getImageDescriptor(String path) {
return imageDescriptorFromPlugin(PLUGIN_ID, path);
}
}
ImageRegistryExample
Méthode généré par l’assistant
de création du plugin
Création d’un ImageDescriptor à
partir du chemin du plug-in
Ajout de l’ImageDescriptor
dans le registre d’images

View Slide

107
Exemple (suite) : utilisation de l’ImageRegistry d’un plug-in
public class ImageRegistryView extends ViewPart {
parent.setLayout(new GridLayout(1, false));
Label myImage = new Label(parent, SWT.NONE);
GridData gd = new GridData(GridData.FILL_BOTH);
myImage.setLayoutData(gd);
myImage.setImage(Activator.getDefault().getImageRegistry().get(Activator.SUPERSTAR));
}
}
ImageRegistryView.java du projet
ImageRegistryExample
Utilisation du registre
d’images pour accéder à
une image

View Slide

108
Structure d’un plug-in : Platform
La classe Platform est centrale à la plateforme d’exécution
d’une application Eclipse
Elle est donc transverse et fournit les caractéristiques
principales liées aux plateformes
Des registres des extensions
Des logs
Des informations relatives à l’environnement d’exécution
Différentes autres informations, non étudiées dans ce cours
Platform est une classe singleton et toutes les méthodes sont
définies comme statiques
Dans la suite, nous présentons les principales méthodes liées
aux logs et aux informations de l’environnement d’exécution
Concernant les registres des extensions, les méthodes seront
étudiées dans la partie suivante

View Slide

109
Platform : logs
La classe Platform fournit une méthode pour s’abonner aux
envois de logs vers la plateforme Eclipse
static void addLogListener(ILogListener listener) : abonnement aux
écouteurs de type ILogListener
L’écouteur ILogListener fournit une méthode qui est déclen-
chée quand un log est envoyé vers la plateforme
void logging(IStatus status, String plugin) : status contient les
informations transmises au log, plugin définit le nom du plug-in
émetteur du log
Pour rappel, rien n’empêche d’utiliser conjointement une
librairie externe comme Log4j

View Slide

110
Platform : logs
Exemple : rediriger les Logs de la plateforme Eclipse
L’action « Creation d’un Log » poste un log
vers la plateforme. L’écouteur ajouté à la
plateforme permet d’afficher le contenu du log
.log du workspace
PlatformLogExample

View Slide

111
Platform : logs
Exemple (suite) : rediriger les Logs de la plateforme Eclipse
public class PlatformLog extends ViewPart {
...
Button myLogAction = new Button(parent, SWT.NONE);
myLogAction.setText("Creation d'un Log");
Platform.addLogListener(new ILogListener() {
public void logging(IStatus status, String plugin) {
myText.append("Message envoyé : (" + status.getMessage()
+ ") par le plug-in : " + plugin);
}
});
myLogAction.addSelectionListener(new SelectionAdapter() {
Activator.getDefault().getLog().log(
new Status(IStatus.INFO, Activator.PLUGIN_ID, 0,
"Action sur le Bouton a l'instant : " + System.currentTimeMillis(), null));
}
});
}
}
PlatformLog.java du projet
PlatformLogExample
Création d’un log
Abonnement à un écouteur de
type ILogListener pour rediriger
le contenu des logs

View Slide

112
Platform : informations de l’environnement d’exécution
La classe Platform fournit des méthodes pour obtenir des
informations sur la plateforme d’exécution
String getNL() : locale en cours d’utilisation
String getOS() : système d’exploitation utilisé
String getOSArch() : l’architecture de la machine
String getWS() : le type de version du système utilisé
La classe Platform fournit également un ensemble de métho-
des pour connaître les valeurs de certains chemins
Location getUserLocation() : répertoire de travail de l’utilisateur
Location getInstallLocation() : répertoire d’installation de l’application
Eclipse en cours d’exécution
Location getConfigurationLocation() : répertoire utilisé pour stocker la
configuration d’exécution
Location getInstanceLocation() : répertoire du workspace de
l’application Eclipse en cours d’exécution

View Slide

113
Exemple : informations de l’environnement d’exécution
public class PlatformOS extends ViewPart {
Button myOSInformation = new Button(parent, SWT.NONE);
myOSInformation.setText("Informations sur l'OS");
myOSInformation.addSelectionListener(new SelectionAdapter() {
myText.append(Platform.getNL() + "\n");
myText.append(Platform.getOS() + "\n");
myText.append(Platform.getOSArch() + "\n");
myText.append(Platform.getWS() + "\n");
myText.append("Repertoire utilisateur : " +
Platform.getUserLocation().getURL().toString());
myText.append("Repertoire d'installation : " +
Platform.getInstallLocation().getURL().toString());
myText.append("Repertoire du workspace : " +
Platform.getInstanceLocation().getURL().toString());
}
});
}
}
PlatformOS.java du projet
PlatformOSExample
Affichage des informations
liées à l’environnement
d’exécution

View Slide

114
La classe Platform fournit des méthodes pour obtenir les
arguments passées en paramètres lors de l’exécution de
une application Eclipse
String[] getApplicationArgs() : retourne tous les arguments non
consommés par la plateforme Eclipse
String[] getCommandLineArgs() : retourne tous les arguments même
ceux consommés par la plateforme Eclipse
Un argument est désigné comme une chaîne de caractères
sans espace
Exemple : -test option1=alpha (correspond à deux arguments)
En général, si vous souhaitez ajouter des options spécifiques
à votre application Eclipse utiliser la méthode
getApplicationArgs()

View Slide

115
Exemple : extraire les arguments passés en paramètres
public class PlatformCommandParams extends ViewPart {
...
Button myParameterAction = new Button(parent, SWT.NONE);
myParameterAction.setText("Informations Parametre Commandes");
myParameterAction.addSelectionListener(new SelectionAdapter() {
String[] applicationArgs = Platform.getApplicationArgs();
myText.append("Application Args" + "\n");
for (int i = 0; i < applicationArgs.length; i++) {
myText.append(applicationArgs[i].toString() + "\n");
}
myText.append("\n\n" + "CommandLine Args" + "\n");
String[] commandArgs = Platform.getCommandLineArgs();
for (int i = 0; i < commandArgs.length; i++) {
myText.append(commandArgs[i].toString() + "¥n");
}
}
});
}
}
PlatformCommandParams.java du projet
PlatformCommandParamsExample
Deux arguments ont été ajoutés
-test et -name=BARON_MICKAEL

View Slide

116
Bilan …
Nous avons étudié …
Une introduction à OSGi
Le développement par l’exemple d’un plug-in simple
Le contenu des fichiers de configuration (MANIFEST.MF, plugin.xml,
build.properties)
La description des classes Activator et Platform
Nous n’avons pas étudiés, prochainement dans ce cours
L’internationalisation des plug-ins
Prochaine étape : Extensions et Points d’extension
Etudier plus en détail la notion d’extensions et de points d’extension
Définir un point d’extension via un schéma XSD
Définir une extension et respecter le schéma

View Slide

117
Glossaire Eclipse
Bundle ou plug-in : un bundle est un composant qui possède un
cycle de vie et qui expose et importe des services. Sous Eclipse le
composant est appelé plug-in
Extension : l’extension est la réponse apportée à un point d’extension
Il doit respecter un schéma imposé par le point d’extension
IHM : acronyme qui a une signification différente selon s’il est singulier
ou pas : au singulier, il signifie le domaine de l’Interaction Homme-
Machine, au pluriel, il signifie les Interfaces Homme-Machine
LazyLoading : qui désigne la politique de chargement d’un plug-in.
Le plug-in est chargé dans le conteneur OSGi quand il doit être utilisé
MANIFEST.MF : fichier de configuration qui décrit le fonctionnement
d’une archive Jar. La spécification OSGi enrichie sa description en ajoutant
des descriptions générales (nom, auteur, version) et des descriptions de
dépendances avec les autres plug-ins

View Slide

118
Glossaire Eclipse
PDE : Plug-in Development Environment est un ensemble d’outils
fournit par l’environnement Eclipse pour faciliter le développement des
plug-ins
perspective : regroupement cohérent de vues (views) et d’actions
spécifiques à une tâche de l’utilisateur (coder du Java, débuguer, …)
plugin.xml : un fichier de configuration au format XML qui décrit les
extensions et les points d’extension utilisés et fournis par un plug-in
point d’extension : un point d’extension décrit un contrat qui
stipule la manière dont des interfaces et des classes d’un plug-in doivent
être utilisées par d’autres plug-ins. Le contrat est décrit au travers un
schéma XML
product : configuration utilisée pour la génération d’une version
exécutable de l’application Eclipse (les plug-ins dépendants, les
arguments pour l’exécution de l’application, les icônes, le splashscreen)

View Slide

119
Glossaire Eclipse
RCP : Rich Client Platform est une application autonome basée sur le
noyau Eclipse. Tous les aspects liés à l’environnement de développement
ont été supprimés
view : un élément graphique qui permet d’afficher une IHM. Une View
est disponible par l’intermédiaire d’une perspective
workspace : correspond à un espace de travail dans lequel l’applica-
tion Eclipse peut déposer les fichiers qui ont été manipulés
Glossaire complété dans la suite des
partie de ce chapitre

View Slide

Eclipse : développement de plug-ins

Eclipse : développement de plug-ins

Mickael BARON

More Decks by Mickael BARON

Other Decks in Programming

Featured

Transcript