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] mickael-baron.fr mickaelbaron Chapitre 3 : Conception de plug-ins Introduction à la conception de plug-ins

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

mickaelbaron 3 À propos de l’auteur … Mickaël BARON Ingénieur de Recherche au LIAS https://www.lias-lab.fr Equipe : Ingénierie des Données et des Modèles Responsable des plateformes logicielles, « coach » technique Ancien responsable Java de Developpez.com (2011-2021) Communauté Francophone dédiée au développement informatique https://java.developpez.com 4 millions de visiteurs uniques et 12 millions de pages vues par mois 750 00 membres, 2000 forums et jusqu'à 5000 messages par jour mickael-baron.fr mickaelbaron

mickaelbaron 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 mickael-baron.fr/eclipse/intro-plugin

mickaelbaron 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

mickaelbaron 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

mickaelbaron 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

mickaelbaron 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)

mickaelbaron OSGi : Open Service Gateway Initiative 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

mickaelbaron OSGi : Open Service Gateway Initiative 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

mickaelbaron OSGi : Open Service Gateway Initiative 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)

mickaelbaron OSGi et Eclipse Dans l’implémentation fournie par Eclipse, un bundle correspond à 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/

mickaelbaron 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)

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

mickaelbaron 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)

mickaelbaron 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

mickaelbaron 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

mickaelbaron 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

mickaelbaron 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

mickaelbaron 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

mickaelbaron 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

mickaelbaron 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)

mickaelbaron Tutoriel « plug-hype » : exécuter dans Eclipse Sélectionner à partir du menu Eclipse l’action Run -> Open Run Dialog … Ou à partir de la barre d’actions

mickaelbaron Tutoriel « plug-hype » : exécuter dans Eclipse 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

mickaelbaron Tutoriel « plug-hype » : exécuter dans Eclipse 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

mickaelbaron Tutoriel « plug-hype » : exécuter dans Eclipse 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

mickaelbaron Tutoriel « plug-hype » : exécuter dans Eclipse Cet onglet autorise l’enregistrement du fichier de configuration 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éé

mickaelbaron Tutoriel « plug-hype » : exécuter dans Eclipse 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

mickaelbaron Tutoriel « plug-hype » : exécuter dans Eclipse 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

mickaelbaron 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 fonctionnement 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

mickaelbaron 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

mickaelbaron Structure d’un plug-in : MANIFEST.MF Le fichier de configuration MANIFEST.MF décrit le fonctionnement 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

mickaelbaron 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

mickaelbaron 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)

mickaelbaron MANIFEST.MF : informations générales 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)

mickaelbaron MANIFEST.MF : informations générales 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)

mickaelbaron MANIFEST.MF : informations générales 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

mickaelbaron 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

mickaelbaron MANIFEST.MF : informations de dépendance 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

mickaelbaron MANIFEST.MF : informations de dépendance 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

mickaelbaron MANIFEST.MF : informations de dépendance 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

mickaelbaron MANIFEST.MF : informations de dépendance 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

mickaelbaron MANIFEST.MF : informations de dépendance 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

mickaelbaron MANIFEST.MF : informations de dépendance 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

mickaelbaron MANIFEST.MF : informations de dépendance MANIFEST.MF du projet 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)

mickaelbaron 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

mickaelbaron 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

mickaelbaron 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, . MANIFEST.MF du projet ExportExample L’arborescence des fichiers et répertoires du plug-in ExportExample Seul le package eclipse.plugin.exportexample est public

mickaelbaron MANIFEST.MF : exemple (dépendance + exportation) 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; } package eclipse.plugin.exportexample; 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

mickaelbaron MANIFEST.MF : exemple (dépendance + exportation) 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 projet ExportExample L’implémentation n’est pas public La bibliothèque XStream permet de sérialiser et dé- sérialiser le contenu de cet objet

mickaelbaron MANIFEST.MF : exemple (dépendance + exportation) 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

mickaelbaron MANIFEST.MF : exemple (dépendance + exportation) 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 widgetSelected(SelectionEvent e) { ... } }); } 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

mickaelbaron MANIFEST.MF : exemple (dépendance + exportation) Exemple (suite) : plug-in DependenciesExample MANIFEST.MF du projet DependenciesExample Le plug-in ExportExample est ajouté dans les dépendances de manière à intégrer la partie modèle dans l’IHM

mickaelbaron 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

mickaelbaron 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

mickaelbaron 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 MANIFEST.MF du projet ExportExample

mickaelbaron 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

mickaelbaron Transformation d’une librairie en plug-in 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

mickaelbaron Transformation d’une librairie en plug-in 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

mickaelbaron Transformation d’une librairie en plug-in 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

mickaelbaron Transformation d’une librairie en plug-in MANIFEST.MF du projet 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

mickaelbaron Transformation d’une librairie en plug-in Au moment de l’exécution de l’action de désérialisation, un exception est lancée La classe SerializeName est introuvable

mickaelbaron Transformation d’une librairie en plug-in 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

mickaelbaron Transformation d’une librairie en plug-in 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

mickaelbaron Transformation d’une librairie en plug-in Modification de la politique de chargement du classloading du plug-in XStream MANIFEST.MF du projet com.thoughworks.xstream MANIFEST.MF du projet 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

mickaelbaron 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

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

mickaelbaron Structure d’un plug-in : plugin.xml 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

mickaelbaron Structure d’un plug-in : plugin.xml 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

mickaelbaron Structure d’un plug-in : plugin.xml 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 plugin.xml du projet DependenciesExample

mickaelbaron Structure d’un plug-in : plugin.xml Création des points d’extension via l’outil PDE Création des points d’extension via l’onglet Extensions Points plugin.xml du projet DependenciesExample Ce plug-in ne fournit pas de point d’extension

mickaelbaron 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.<library> : liste les répertoires sources qui seront compilés output.<library> : 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

mickaelbaron Structure d’un plug-in : build.properties 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 projet ExportExample 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

mickaelbaron Structure d’un plug-in : build.properties Exemple (suite) : build.properties du plug-in ExportExample bin.includes sources..

mickaelbaron 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 »

mickaelbaron Déployer les plug-ins 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

mickaelbaron Déployer les plug-ins 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

mickaelbaron Déployer les plug-ins 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

mickaelbaron 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

mickaelbaron 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

mickaelbaron Activator : cycle de vie 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

mickaelbaron Activator : cycle de vie 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

mickaelbaron Activator : cycle de vie 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

mickaelbaron Activator : cycle de vie Exemple (suite) : principe de LazyLoading d’un plug-in package eclipse.plugin.exportexample; 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 } } Activator.java du projet 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

mickaelbaron Activator : cycle de vie Exemple (suite) : principe de LazyLoading d’un plug-in package eclipse.plugin.lazyloadingexample; public class LazyLoadingView extends ViewPart { public void createPartControl(Composite parent) { ... createButton.addSelectionListener(new SelectionAdapter() { public void widgetSelected(SelectionEvent e) { if (!isCreated) { saveSerialization.setEnabled(true); loadSerialization.setEnabled(true); createButton.setEnabled(false); isCreated = true; currentSerializeFactory = Activator.getDefault().getSerializeInstance(); } } }); ... saveSerialization.addSelectionListener(new SelectionAdapter() { public void widgetSelected(SelectionEvent e) { 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

mickaelbaron Activator : cycle de vie Exemple (suite) : principe de LazyLoading d’un plug-in package eclipse.plugin.lazyloadingexample; public class LazyLoadingView extends ViewPart { public void createPartControl(Composite parent) { ... loadSerialization = new Button(parent, SWT.NONE); loadSerialization.addSelectionListener(new SelectionAdapter() { public void widgetSelected(SelectionEvent e) { 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

mickaelbaron 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, …)

mickaelbaron Activator : informations sur le Bundle Exemple : accéder aux informations du Bundle d’un plug-in public class BundleExample extends ViewPart { public void createPartControl(Composite parent) { ... Button myBundleInformation = new Button(parent, SWT.NONE); final Text myText = new Text(parent, SWT.WRAP); ... myBundleInformation.addSelectionListener(new SelectionAdapter() { public void widgetSelected(SelectionEvent e) { 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

mickaelbaron 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)

mickaelbaron Activator : gestion des préférences d’un plug-in 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

mickaelbaron Activator : gestion des préférences d’un plug-in 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

mickaelbaron Activator : gestion des préférences d’un plug-in 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

mickaelbaron Activator : gestion des préférences d’un plug-in 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

mickaelbaron Activator : gestion des préférences d’un plug-in Exemple (suite) : gestion des préférences dans un plug-in public class PreferenceView extends ViewPart { public void createPartControl(Composite parent) { ... loadPreference.addSelectionListener(new SelectionAdapter() { public void widgetSelected(SelectionEvent e) { loadPreferences(); } }); savePreference.addSelectionListener(new SelectionAdapter() { public void widgetSelected(SelectionEvent e) { 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() { Preferences preferences = Activator.getDefault().getPluginPreferences(); 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

mickaelbaron Activator : gestion des préférences d’un plug-in 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

mickaelbaron Activator : gestion des préférences d’un plug-in Exemple : initialisation des préférences par défaut plugin.xml du projet 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

mickaelbaron Activator : gestion des préférences d’un plug-in 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

mickaelbaron Activator : gestion des préférences d’un plug-in Exemple (suite) : initialisation des préférences par défaut L’élément initializer requiert une classe de type AbstractPreferenceInitializer plugin.xml du projet PreferenceExample Onglet Extensions pour définir des extensions

mickaelbaron Activator : gestion des préférences d’un plug-in Exemple (suite) : initialisation des préférences par défaut package eclipse.plugin.preferenceexample; public class PreferenceInitializer extends AbstractPreferenceInitializer { public PreferenceInitializer() { } public void initializeDefaultPreferences() { Preferences preferences = Activator.getDefault().getPluginPreferences(); 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

mickaelbaron 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é

mickaelbaron Activator : gestion des Logs 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)

mickaelbaron Activator : gestion des Logs Exemple : utilisation du gestionnaire de Logs d’Eclipse .log du workspace LogExample LogView du projet LogExample Lors de l’appui sur le bouton Action to log, un log est posté dans le fichier .log

mickaelbaron Activator : gestion des Logs Exemple (suite) : utilisation du gestionnaire de Logs d’Eclipse public class Activator extends AbstractUIPlugin { ... public void start(BundleContext context) throws Exception { super.start(context); 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)); } ... } Activator.java du projet LogExample Lors du démarrage du plug-in un log est posté dans le fichier .log

mickaelbaron Activator : gestion des Logs Exemple (suite) : utilisation du gestionnaire de Logs d’Eclipse public class LogView extends ViewPart { public LogView() { } public void createPartControl(Composite parent) { parent.setLayout(new FillLayout()); Button myCurrentButton = new Button(parent, SWT.FLAT); myCurrentButton.addSelectionListener(new SelectionAdapter() { public void widgetSelected(SelectionEvent e) { 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 Lors de l’appui sur le bouton « Action to log », un log est posté dans le fichier .log

mickaelbaron 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

mickaelbaron 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 nouveau 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

mickaelbaron AbstractUIPlugin : ImageRegistry Exemple : utilisation de l’ImageRegistry d’un plug-in public class Activator extends AbstractUIPlugin { ... public static final String SUPERSTAR = "SUPERSTAR"; public void start(BundleContext context) throws Exception { super.start(context); 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); } } Activator.java du projet 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

mickaelbaron AbstractUIPlugin : ImageRegistry Exemple (suite) : utilisation de l’ImageRegistry d’un plug-in public class ImageRegistryView extends ViewPart { public void createPartControl(Composite parent) { 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

mickaelbaron 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

mickaelbaron 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

mickaelbaron 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

mickaelbaron Platform : logs Exemple (suite) : rediriger les Logs de la plateforme Eclipse public class PlatformLog extends ViewPart { public void createPartControl(Composite parent) { ... Button myLogAction = new Button(parent, SWT.NONE); myLogAction.setText("Creation d'un Log"); final Text myText = new Text(parent, SWT.WRAP); 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() { public void widgetSelected(SelectionEvent e) { 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

mickaelbaron 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

mickaelbaron Platform : informations de l’environnement d’exécution Exemple : informations de l’environnement d’exécution public class PlatformOS extends ViewPart { public void createPartControl(Composite parent) { Button myOSInformation = new Button(parent, SWT.NONE); myOSInformation.setText("Informations sur l'OS"); final Text myText = new Text(parent, SWT.WRAP); myOSInformation.addSelectionListener(new SelectionAdapter() { public void widgetSelected(SelectionEvent e) { 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

mickaelbaron Platform : informations de l’environnement d’exécution 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()

mickaelbaron Platform : informations de l’environnement d’exécution Exemple : extraire les arguments passés en paramètres public class PlatformCommandParams extends ViewPart { public void createPartControl(Composite parent) { ... Button myParameterAction = new Button(parent, SWT.NONE); myParameterAction.setText("Informations Parametre Commandes"); final Text myText = new Text(parent, SWT.WRAP); myParameterAction.addSelectionListener(new SelectionAdapter() { public void widgetSelected(SelectionEvent e) { 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

mickaelbaron 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

mickaelbaron 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

mickaelbaron 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)

mickaelbaron 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’application Eclipse peut déposer les fichiers qui ont été manipulés Glossaire complété dans la suite des partie de ce chapitre

Eclipse : développement de plug-ins

Eclipse : développement de plug-ins

More Decks by Mickael BARON

Other Decks in Programming

Featured

Transcript