Développez vos propres plugins pour Eclipse, partie 1

Eclipse est un bon IDE, bien sûr, mais il est surtout la meilleure plateforme pour héberger vos propres applications. Utiliser les outils fournis par Eclipse vous épargne le ré-développement, pour la 100e fois, d'un framework qui s'occupe de l'aide en ligne, d'assistants de générations, ou de sauvegardes d'un fichier sur le disque dur. Eclipse embarque de nombreuses et utiles fonctionnalités, tel qu'un moteur déjà configuré pour Lucene pour rechercher la documentation. Comme tout développeur ayant de bonnes connaissances en programmation objet, vous ne voulez pas réinventer la roue.

Cette série d'articles a pour but de vous fournir les informations de bases nécessaires au codage rapide de votre premier plugin. La section « Ressources » fournira des liens vers toutes les ressources introduites par ces articles. Le premier volume va présenter l'application qui va être construite, tout le vocabulaire requis et va expliquer comment emballer vos plugins. Veuillez noter que nous utilisons le terme ${eclipse.home} pour indiquer le répertoire par défaut d'Eclipse, c'est-à-dire le répertoire où figurent eclipse.exe ou le fichier eclipse.sh.

Avez-vous déjà essayé de configurer Tomcat ou Jetty ? Avez-vous jamais comparé les fichiers de configuration de Tomcat 4 et de Tomcat 5 ? C'est un cauchemar, et cela vous force à prendre la documentation et à chercher chaque paramètre pour vérifier s'il a une valeur par défaut, vous demander ce que c'est, « Pourquoi avais-je changé la valeur par défaut ? », etc. C'est pourquoi, nous allons voir ce qui pourrait devenir votre ami de tous les jours : une petite application qui n'a d'autres buts que de générer rapidement des fichiers de configuration robustes pour votre conteneur de servlets. Bien sûr, les serveurs de production et les IDEs n'ont pas les mêmes contraintes, et à moins d'utiliser de la magie noire, comment ce logiciel pourrait générer le bon fichier pour la bonne utilisation ? Se poser la question nous donne la solution : cette application sera conçue comme un assistant qui vous guidera tout au long du processus de génération. La figure 1 représente l'écran d'accueil de ce plugin. Cette petite application est assez simple pour être étudiée aujourd'hui, tout en nous permettant d'exposer certains aspects intéressants sur les pratiques de codages d'Eclipse.

Figure 1. Le plugin de création des fichiers de configuration

Avant d'entrer plus avant dans les détails, analysons le vocabulaire propre au codage avec la plateforme Eclipse. En fournissant un plugin, vous agissez en tant que contributeur, c'est-à-dire que vous étendez les fonctionnalités du produit avec votre propre travail. C'est le principe majeur d'Eclipse, où tout est un plugin. Pour clarifier : tout, excepté une petite partie, du code d'Eclipse est un plugin -- cette petite partie est appelé le noyau et a pour but d'offrir les outils nécessaires au chargement du produit et d'instancier les plugins embarqués. La figure 2 fournit une idée basique de la structure interne d'Eclipse.

Figure 2. Présentation de l'architecture d'Eclipse

Cette figure est une vue simplifiée de ce qui est fourni par défaut avec le package Eclipse. Pour une idée plus précise des plugins disponibles lors du chargement, veuillez vous référer au répertoire ${eclipse.home}/plugins. La figure 3 montre le contenu de ce répertoire comme fourni par défaut par Eclipse 3.OM9.

Figure 3. Contenu du répertoire des plugins

Étrange, n'est-ce pas ? Une importante série de répertoires avec des noms comparables aux packages Java. Ainsi nous savons que tout application doit être placée dans le répertoire plugins, et que chaque plugin est mis dans un répertoire ayant un nom utilisant une convention basée sur les points. Nous devons maintenant comprendre comment ce répertoire est composé.

Quelle est la structure de ces répertoires ? Pour utiliser une métaphore simple du monde Java, les plugins sont déployés dans le framework Eclipse d'une manière similaire aux web applications ou EJBs dans le monde J2EE. C'est-à-dire que ce fichier .zip contiendra votre code (si le code est nécessaire) et les ressources (tout fichier de configuration, d'aide, les images, etc.). Toutes ces choses doivent être proprement organisées afin de permettre au cœur du framework de charger votre plugin. C'est la où la magie d'XML entre en jeu. Une métadonnée XML va être utilisé pour déclarer ce qu'il y a dans votre plugin. Cette métadonnée est stockée dans le répertoire racine de chaque plugin, dans un fichier nommé plugin.xml. En utilisant les plugins par défaut embarqués avec Eclipse, nous pouvons examiner ces fichiers. Regardons ce plugin qui amène Lucene dans le framework Eclipse :

<?xml version="1.0" encoding="UTF-8"?>

<?eclipse version="3.0"?>

<plugin

   id="org.apache.lucene"

   name="%lucene_plugin_name"

   version="1.3.0.RC2"

   provider-name="%providerName">



   <runtime>

      <library name="parser.jar">

         <export name="*"/>

         <packages

         prefixes="org.apache.lucene.demo.html"/>

      </library>

      <library name="lucene-1.3-rc2.jar">

         <export name="*"/>

         <packages

         prefixes="org.apache.lucene"/>

      </library>

   </runtime>

</plugin>

Ce fichier déclare un plugin (le tag plugin) pour la version 3 de la plateforme Eclipse. (Notez que ce n'est pas une fonctionnalité spécifique à Eclipse, mais une manière XML typique pour être correctement interprété par le processeur XML.) Ces attributs plugin définissent un identifiant unique, un nom, une version et le fournisseur (l'équipe Eclipse, vous ou n'importe qui d'autre). Puis une section nommée Runtime est utilisée pour déclarer les libraires nécessaires au bon fonctionnement du plugin. Dans cet exemple, deux libraires sont requises pour avoir un plugin Lucene fonctionnel.

Si vous avez déjà ajouté des plugins à la plateforme Eclipse, vous avez probablement vu que certains plugins ajoutent des entrées dans le menu contextuel (clic-droit), tandis que d'autres ajoutent des nouvelles vues ou perspectives. Le fichier plugin.xml est l'endroit où vous indiquez l'information définissant le type d'extension que le plugin va fournir. Un plugin peut fournir de nouvelles fonctionnalités à la plateforme Eclipse tout en ajoutant des nouvelles ressources pour tout point d'extension. Eclipse définit certains points d'extension, tels que des menus, des assistants, des vues et des perspectives. C'est là où la beauté du produit se montre réellement : chaque objet vu dans l'interface utilisateur d'Eclipse peut être entièrement customisée. Notre exemple futur nous montrera comment déclarer que notre application ajoute certaines entrées dans la plateforme Eclipse. Mais d'abord, regardons ce que peut être le plugin le plus simple.

Je ne peux pas conclure cet article sans vous donner un tout petit peu plus pour aiguiser votre appétit, alors nous allons essayer de créer un premier plugin simple. Mais s'il vous plaît, ne soyez pas trop impatient, et n'attendez rien de plus de ce plugin que d'être chargé correctement par la plateforme Eclipse. Si vous utilisez le fichier plugin.xml suivant :

<?xml version="1.0" encoding="UTF-8"?>

<?eclipse version="3.0"?>

<plugin

   id="com.javaxpert.eclipse.plugins.dummy"

   name="%plugin_name"

   version="1.0.0"

   provider-name="%providerName">



   <runtime>

      <library >

      </library>

      <requires/>

   </runtime>



</plugin>

Et le fichier de propriétés suivant (plugin.properties)

plugin_name=My first plugin

providerName=J.MOLIERE

Vous devriez être capable de voir votre plugin chargé dans la plateforme Eclipse (après avoir stoppé et redémarré Eclipse) dans la page d'information des plugins disponible dans le menu « À propos ». La figure 4 montre la boîte « À propos » section Plugins ») pour Eclipse 3M9 avec notre plugin chargé.

Figure 4. Notre plugin dans la liste de la boîte de dialogue « À propos d'Eclipse »

Je ne peux conclure sans donner quelques indications pour comprendre le fichier plugin.xml. Cette métadonnée XML déclare un plugin avec un nom identifié, et dans la mesure où il ne fournit pas une nouvelle à la plateforme, son tag library est vide. De plus il ne nécessite pas d'autres plugins pour fonctionner, c'est pourquoi le tag requires est vide. Le prochain article montrera un plugin plus réaliste qui nécessite d'autres plugins à charger.

C'est la fin de cette rapide présentation du développement du plugin pour Eclipse. Maintenant, nous avons les bases ; le prochain article permettra d'entrer dans les détails de codages avec un plugin réel. Bonne programmation.

Remerciements à regbegpower pour avoir traduit cet article de l'anglais.