I. Présentation générale▲
I-A. Licences, brevets et propriété intellectuelle▲
Comme pour tout projet open source le premier point auquel il faut s'intéresser est bel et bien juridique. En effet depuis septembre 2005, la plate-forme Eclipse est distribuée sous licence EPL (Eclipse Public Licence) et non plus sous licence CPL (Common Public Licence), nous décrirons donc ces deux licences et verrons leurs principales différences, nous évoquerons ensuite la question des brevets placés sur le code source et la propriété intellectuelle de ce dernier.
I-A-1. Licences CPL et EPL▲
Licences CPL et EPL sont toutes les deux reconnues par l'OSI (Open Source Initiative), elles garantissent la fourniture du code source à tout utilisateur. Par contre tout contributeur souhaitant modifier une application sous licence CPL ou EPL devra renseigner son nom ou celui de sa société au niveau du code. Par ailleurs, la redistribution du code se fait obligatoirement sous la même licence : à l'instar de la licence GPL (GNU General Public Licence), les licences CPL et EPL sont virales. Par opposition au copyright certains parlent de copyleft.
Les différences entre les licences CPL et EPL sont plutôt historiques. Lorsque IBM a proposé le code source d'Eclipse en 2001 la licence choisie a été la CPL, cette licence engageait tout contributeur vis-à-vis de l'éditeur. Or depuis 2001 le code source d'Eclipse est géré par la fondation Eclipse qui regroupe un grand nombre d'éditeurs comme Sybase, BEA, Zend, etc. qui contribuent également à l'évolution de la plate-forme. La licence EPL ne mentionne donc plus IBM et ne lui est donc plus directement favorable.
I-A-2. Brevets▲
Un certain nombre de brevets logiciels ont été déposés sur le code source d'Eclipse, et en particulier sur le code source fourni par IBM. Pour le moment les brevets logiciels ne sont pas reconnus par le droit européen, par contre si la législation évoluait les détenteurs de ces brevets pourraient exercer leurs droits. Notons toutefois que la licence EPL est plus souple sur le sujet avec la suppression d'un article de la licence CPL favorable aux brevets. Par ailleurs IBM s'est engagé en 2005 à ne pas exercer ses droits sur 500 de ses brevets à condition qu'ils soient utilisés dans des projets Open Source comme Eclipse.
I-B. Interface graphique▲
Après avoir pris connaissance de nos droits et installé Eclipse, nous prenons connaissance de l'environnement graphique qui au premier abord est plutôt convivial et performant. Intéressons-nous aux API qui permettent l'implémentation de ces interfaces, à savoir SWT (Standard Widget Toolkit) et JFace.
I-B-1. SWT▲
SWT est une API graphique écrite en Java, indépendante des systèmes d'exploitation mais utilisant les librairies graphiques de ces derniers. Cette indépendance est rendue possible par l'utilisation de JNI (Java Native Interface). Ainsi lors de l'affichage d'un bouton SWT, c'est en fin de compte un composant natif de la plate-forme d'exécution du programme qui est affiché même si ce dernier a été implémenté en C.
Parmi les avantages des interfaces SWT on notera le même aspect graphique que les applications natives de la plate-forme d'exécution, mais également les temps de réponse et l'occupation mémoire puisque la machine virtuelle délègue cette tâche au système d'exploitation. Cette dernière remarque est à tempérer en fonction du système d'exploitation utilisé, en effet les librairies SWT pour Linux et MacOSX auraient besoin d'être optimisées.
I-B-2. JFace▲
JFace est également une API écrite en Java, mais celle-ci ne s'appuie pas sur le système de fenêtrage du système d'exploitation mais sur l'API SWT pour proposer des composants graphiques plus « riches ». Par exemple pour obtenir le champ de saisie de la figure ci-dessous, vous seriez obligé d'insérer un Label et un champ Text en SWT, alors qu'avec JFace il existe un composant de type StringFieldEditor qui les réunit.
I-C. Le projet Eclipse, une approche modulaire▲
Les fonctionnalités proposées par le projet Eclipse sont nombreuses : que ce soit pour le développement Java avec de multiples assistances à la production de code, le support de CVS comme référentiel de gestion de configuration ou encore le support de framework open source comme JUnit (tests unitaires) ou ANT (déploiement). L'objectif n'est pas de faire la liste exhaustive de toutes ces fonctionnalités mais bien de voir comment elles sont organisées.
Toutes les fonctionnalités du projet Eclipse sont organisées par module, on trouve par exemple le module JDT (Java Development Toolkit) qui réunit toutes les fonctions permettant de développer en Java. Ensuite chaque module est décomposé en sous-modules. Pour le développement Java, on trouve le debug, la compilation, l'exécution, le support de ANT, etc. l'entité de base étant le plug-in.
I-C-1. Définitions▲
L'entité de base étant le plug-in, celui-ci peut se décomposer en fragments ou être placé dans une feature dont le but est d'agréger un ensemble de plug-ins.
I-C-1-a. Plug-in▲
Si l'entité de base est le plug-in, chaque module correspond à un ou plusieurs plug-ins. Nous verrons dans la seconde partie comment créer son propre plug-in, considérons pour le moment qu'un plug-in est un ensemble de fonctionnalités mises à la disposition de la plate-forme. D'un point de vue implémentation le plug-in correspond généralement à une archive Java ou à un répertoire composé de divers ressources (classes Java, images…) et surtout d'un fichier plugin.xml qui est obligatoire et décrit comment s'intègre notre plug-in dans la plate-forme.
Le fichier plugin.xml indique entre autres quels sont les autres plug-ins dont il dépend, mais également les fonctionnalités que lui-même offre aux autres plug-ins : ce sont les points d'extension.
Un point d'extension permet d'identifier une fonctionnalité implémentée sur un plug-in pouvant bénéficier à un autre, et comment le plug-in bénéficiaire devra utiliser et implémenter cette fonctionnalité. Le plug-in bénéficiaire définira alors une extension dans son fichier plugin.xml qui respecte les préconisations du point d'extension.
Pour information, depuis sa version 3.1 Eclipse utilise le standard OSGi (http://www.osgi.org) pour localiser ses services (plug-ins) et les invoquer, la conséquence en termes d'implémentation est que certaines informations jusqu'ici stockées dans le fichier plugin.xml sont désormais accessibles dans le fichier MANIFEST.MF. Cette modification importante au niveau de la plate-forme n'est pas sans conséquence, car les plug-ins existants devront être migrés, mais offre de nouvelles perspectives en termes de déploiement à chaud des plug-ins et de supervision de la plate-forme.
I-C-1-b. Fragment▲
Le fragment est un morceau de plug-in, il est indispensable pour permettre le développement itératif d'un plug-in puisqu'il correspond au complément d'un plug-in existant. Ainsi un plug-in implémentant des fonctionnalités centrales peut être déployé, les modules additionnels comme l'internationalisation seront livrés ultérieurement sous forme de fragments sans toucher au plug-in précédemment déployé.
I-C-1-c. Feature▲
Comme nous l'avons vu un plug-in est toujours dépendant d'au moins un autre plug-in. Cette dépendance peut dans certains cas rendre délicat un changement de version ou la suppression d'un plug-in. Pour faciliter l'intégration d'un ensemble de fonctionnalités, la plate-forme Eclipse dispose d'une notion appelée « Feature ». Ce composant ne fait que référencer un ensemble de plug-ins et leur version. C'est une manière de s'assurer de la cohérence d'un ensemble de plug-ins.
I-C-2. Une modularité à la carte▲
Un des points forts d'Eclipse est sans aucun doute sa modularité que nous venons de voir, par ailleurs cette plate-forme est suffisamment ouverte pour intégrer de nouveaux plug-ins et en supprimer d'autres.
Par exemple, si j'ai besoin de réaliser des IHM en SWT, plutôt que de les coder j'aimerais les dessiner et bénéficier d'un module qui générera le code à ma place.
Imaginons maintenant que certaines fonctionnalités d'Eclipse ne servent pas à son utilisateur comme le module JDT s'il ne fait pas de développement Java, il peut très bien supprimer les plug-ins responsables de ce module et cela se traduira par une simple suppression des répertoires ou Jars correspondants.
I-C-3. Une modularité à l'exécution▲
L'autre objectif de cette décomposition est pour Eclipse de ne charger que les modules dont il a besoin à l'exécution. Ainsi certains modules du JDT seront chargés par Eclipse lorsqu'un utilisateur créera un projet Java sans pour autant charger le module de debug.
I-C-4. Résumons-nous▲
Mis à part son noyau, Eclipse est composé essentiellement de plug-ins. Cette architecture offre une grande flexibilité puisque chaque utilisateur peut composer son propre environnement. Seulement cette opération peut être délicate si le plug-in supprimé est nécessaire à un autre toujours en activité, ce besoin de rationalisation et de supervision des plug-ins installés est aujourd'hui flagrant. Récemment le noyau de la plate-forme Eclipse a évolué dans ce sens avec le support de nouveaux standards garantissant la même flexibilité et une meilleure supervision de l'ensemble des plug-ins.
II. Développer son propre plug-in▲
Après avoir fait un tour d'horizon de la plate-forme, il est temps de contribuer à son développement comme pour tout projet Open Source. Nous allons suivre étape par étape le cycle de développement d'un plug-in simple. Ce plug-in a pour but d'ajouter un bouton dans la barre d'outil d'Eclipse.
II-A. Créer un projet de développement de plugin▲
Depuis Eclipse 3.1 des informations relatives à la communication entre les plug-ins sont stockées dans un fichier MANIFEST.MF.
Attention, le nom de votre projet correspond au nom de votre plug-in et ce nom doit être unique au niveau de la plate-forme.
L'étape suivante consiste à renseigner la « carte d'identité » de notre plug-in (identifiant, version, etc.). Nous pouvons également demander la génération d'une classe « cycle de vie du plug-in », cette classe sera connue par la plate-forme qui invoquera cette classe lors du chargement du plug-in mais également par toutes les autres classes du plug-in.
Possibilité de générer une classe contrôleur gérant le cycle de vie du plug-in, les identifiants, les méthodes métier, etc.
Çà y est, notre environnement pour réaliser notre plug-in est prêt. En cliquant sur le fichier MANIFEST.MF, Eclipse nous propose un environnement graphique pour nous aider à créer les fichiers descripteurs de déploiement de notre plug-in (MANIFEST.MF et plugin.xml)
Les onglets MANIFEST.MF et plugin.xml correspondent aux fichiers que l'on cherche à générer :
- Overview, Dependencies et Runtime permettent de renseigner le fichier MANIFEST.MF alors que Extension et Extension Points sont dédiés au fichier plugin.xml.
- Overview reprend les informations renseignées lors de la création du projet ;
- Dependencies indique les plug-ins dont dépend le plug-in en cours de développement ;
- Runtime renseigne les informations nécessaires pour la plate-forme lors de l'exécution du plug-in (librairies nécessaires, visibilité, etc.) ;
- Extension offre une vue d'ensemble des points d'extension implémentés sur le plug-in ;
- Extension Points présente les éventuels points d'extension du plug-in.
Il nous faut donc renseigner ces différents onglets.
II-B. Identifier le plug-in souche▲
L'objectif est ici d'identifier le plug-in dont nous avons besoin et d'indiquer son identifiant dans l'onglet Dependencies. Pour identifier le plug-in souche nous avons le choix entre parcourir le million de lignes de code de la distribution d'Eclipse ou trouver une petite méthodologie.
Pour cela, effectuer une recherche (CTRL + H) sur les plug-ins dont le nom commence par org.eclipse.ui, nous obtenons une dizaine de résultats. Cette recherche nous permet de consulter le manifeste de chaque plug-in et d'obtenir des renseignements sur ses points d'extension.
En sélectionnant org.eclipse.ui nous obtenons plusieurs onglets dans la partie édition. L'ensemble de ces onglets permet de décrire le plug-in ainsi sélectionné.
Onglets décrivant le plug-in sélectionné
En sélectionnant l'onglet extension point, on constate que ce plug-in dispose d'un certain nombre de points d'extension, c'est-à-dire autant d'axes permettant de modifier l'interface graphique de base d'Eclipse.
Un de ces points d'extension s'appelle actionSets, en le sélectionnant la partie de droite de cet écran affiche le détail de ce point d'extension (Id, name, schéma) et deux liens permettant d'avoir plus de détails.
En cliquant sur « Open extension point description », on obtient un descriptif sur l'utilité et l'utilisation de ce point d'extension. En l'occurrence actionSets permet d'ajouter menus, sous-menus et barre d'outils dans l'espace de travail d'Eclipse.
Résumons-nous, nous venons d'identifier le plug-in souche (org.eclispe.ui) et son point d'extension (org.eclispe.ui actionSets) qui vont nous permettre d'ajouter un composant graphique sur l'interface. Il nous reste à déclarer le fruit de nos recherches dans les onglets Dependencies et Extension de notre plug-in. Bien entendu cette tâche est un peu fastidieuse mais néanmoins indispensable… à nous de mémoriser les points d'extension les plus récurrents.
II-C. Greffer notre plug-in sur un point d'extension▲
Via l'onglet Extension, nous allons déclarer vouloir étendre le point d'extension org.eclispe.ui.actionSets de manière graphique. À partir de cet instant nous sommes guidés pour définir tous les éléments obligatoires de cette extension (définir un menu, une action, etc.). Pour nous guider, l'environnement de développement s'appuie sur la définition qui a été faite lors de la création du point d'extension que l'on souhaite étendre, techniquement il s'agit d'un fichier XML- Schema qui nous guide dans la création du fichier plug-in.xml (fichier actionSets.exsd).
Notre extension est faite, nous pouvons tester notre plug-in.
II-D. Tester notre plug-in▲
L'environnement de développement de plug-in permet d'émuler une nouvelle instance d'Eclipse dans laquelle notre plug-in serait déployé.
On constate qu'un nouveau bouton a été ajouté à notre interface graphique, et qu'on peut gérer les propriétés d'affichage de ce bouton dans le menu Window > Customize perspective > commands
II-E. Packaging et déploiement▲
Dans la première partie, nous avons écrit qu'un plug-in se présente sous la forme d'un répertoire ou de jar dans lequel se trouvent toutes les ressources nécessaires au plug-in. Le packaging d'un plug-in se déroule en deux étapes.
La première consiste à indiquer dans l'onglet Build, toutes les ressources à inclure dans le plug-in ainsi que celles qu'il faut compiler.
La seconde étape se résume à la génération du plug-in lors d'un export. Le générateur suivra les préconisations de la première étape pour mener à bien cette tâche.
Permet d'indiquer si on souhaite un Jar pour le packaging :
Voilà notre plug-in est généré, il ne nous reste plus qu'à le diffuser pour que tous les utilisateurs d'Eclipse puissent bénéficier de cette nouvelle fonctionnalité.
III. Conclusion▲
Eclipse est sans aucun doute la plate-forme de développement la plus populaire du moment. Les atouts techniques que nous avons présentés dans cet article sont sans aucun doute à l'origine de cette popularité. De là à croire que toutes les opérations que nous avons décrites sont toujours aussi simples à mettre en œuvre, il faut sans aucun doute nuancer. Par exemple, les changements de versions des plug-ins entraînent des incompatibilités voire des conflits avec d'autres plug-ins. De la même manière, nous venons de voir le cycle de développement d'un plug-in simple, pour un plug-in plus élaboré il faudra mettre en œuvre davantage de connaissances et d'expérience. Par exemple pour un plug-in nécessitant une interface graphique il faudra trouver les points d'extension ainsi que la partie de l'API SWT nécessaire pour réaliser ce plug-in. Néanmoins les récentes versions d'Eclipse offrent de nouvelles perspectives avec le support de nouveaux standards comme OSGi pour l'organisation et la supervision des plug-ins installés. Par ailleurs une refonte de l'architecture d'Eclipse permet désormais de considérer cette plate-forme comme un socle capable d'accueillir toute application qu'elle soit destinée au développement ou non. Cette application devra simplement être packagée sous forme de plug-in. Pour reprendre un terme à la mode on parle de Eclipse RCP (Rich Client Patform).
IV. Remerciements▲
Cet article a été mis au gabarit de developpez.com : voici le lien vers le PDF d'origine : OP05-Eclipse-Article.pdf et voici le lien vers le plugin Chat : OP05-Eclipse-Chat-Bonus.zip.
L'équipe Java de Developpez.com tient à remercier la société Valtech pour la mise à disposition de cet article aux membres de Developpez.com.
Nous tenons à remercier également Fabien pour sa relecture attentive de cet article et Régis Pouiller pour la mise au gabarit.