Plugin Eclipse pour O’Caml version 2

La plateforme Eclipse : présentation technique

La plateforme Eclipse a été conçue pour satisfaire les points suivants :
• Fournir un environnement pour le développement d’applications.
• Support pour manipuler des contenus très différents (HTML, Java, C, JSP, XML…)
• Faciliter l’intégration d’outils existants et variés.
• Support pour le développement d’applications graphiques ou non.
• La plateforme est disponible pour de nombreux systèmes d’exploitation (Windows, Unix, MacOSX).
Le principal rôle de la plateforme Eclipse est de fournir un ensemble d’outils définis par des mécanismes et des règles qui constituent l’environnement de développement. Ces mécanismes sont décrits grâce à des API (Application Programming Interface), classes et méthodes. La plateforme fournit également un puissant framework qui facilite le développement de nouveaux outils.
La figure 1 montre les principaux composants et APIs de la plateforme Eclipse.

La plateforme runtime et l’arichitecture Plug-ins

Un plug- in est le plus petit élément de la plateforme Eclipse qui peut être développé et distribué. Dans la majorité des cas, un nouvel outil est développé sous la forme d’un seul plug-in alors que les fonctionnalités d’un outil complexe seront réparties sur plusieurs plug-ins. Toutes les fonctionnalités d’Eclipse sont gérées par des plug-ins sauf pour le noyau de la plateforme appelé plateforme runtime.
Les plug-ins sont entièrement codés en Java. Un plug-in classique est constitué de code Java dans une librairie JAR, de fichiers en lecture seule et d’autres ressources comme des images. Certains plug-ins ne contiennent pas du tout de code. Le plug-in gérant l’aide en ligne en est un exemple. Il existe aussi un mécanisme qui permet à un plug-in d’être défini par un ensemble de fragments de plug-in. Ceci est souvent utilisé pour le support multi langue des plug-ins.
Chaque plug-in est associé à un fichier décrivant les interconnexions avec les autres plug-ins. Ce fichier est appelé manifest file. Le model d’interconnexions est simple : un plug-in déclare un certain nombre de points d’extensions (extension points), et de liens vers d’autres points d’extensions. Le fichier manifeste est un fichier XML.
Un point d’extension d’un plug-in peut être étendu par d’autres plug-ins. Par exemple, le workbench plug-in déclare un point d’extension pour les préférences utilisateurs. Tout autre plug- in a la possibilité d’avoir ses propres préférences utilisateurs en définissant extension du point d’extension du workbench plug-in.
Un point d’extension peut avoir une API correspondante. D’autres plug-ins peuvent contribuer à l’implémentation de cette interface via des extensions des points d’extensions. Tout plug-in peut définir de nouveaux points d’extensions et fournir une nouvelle API.
Au lancement, la plateforme Runtime recherche l’ensemble des plug-ins disponibles, lie les fichiers manifestes et construit une structure de dépendance entre les plug-ins, appelée base de registre des plug-ins. La plateforme associe chaque nom des déclarations d’extension avec les points d’extensions correspondants déclarés. Tous les problèmes détectés, comme l’impossibilité d’associer une déclaration à un point d’extension, sont enregistrés dans un fichier log. Les plug-ins ne peuvent pas être ajoutés après le lancement de la plateforme.
Voici un exemple de fichier manifest d’un plug-in qui définit un nouvel éditeur de texte pour les fichiers d’extension «txt ».
<plugin
id= »MyEditor2″
name= »MyEditor Plug-in »
version= »2.0.0″
provider-name= » »
class= »MyEditor.MyEditorPlugin »>
<extension
point= »org.eclipse.ui.editors »>
<editor
name= »MyEditor »
icon= »icons/sample.gif »
extensions= »txt »
contributorClass= »org.eclipse.ui.editors.text.TextEditorActionContributor » class= »org.eclipse.ui.editors.text.TextEditor » id= »org.eclipse.ui.editors.text.texteditor »>
</editor>
</extension>
</plugin>
Attribut Description
point= »org.eclipse.ui.editors » Point d’extension pour enregistrer
l’éditeur
name= »MyEditor » Nom de l’éditeur
icon= »icons/sample.gif » L’icône qui sera associée à chaque
fichier ouvert avec l’éditeur.
extensions= »txt » Extension de fichier associée à
l’éditeur
contributorClass= »org.eclipse.ui.editors.text.TextEditor Définition des actions du menu.
ActionContributor »
class= »org.eclipse.ui.editors.text.TextEditor » Classe principale de l’éditeur. Ici,
on utilise l’éditeur de texte par
défaut d’Eclipse.
id= »org.eclipse.ui.editors.text.texteditor »> Identificateur unique de l’éditeur.
Ce système de plug-ins est utilisé pour partitionner la plateforme Eclipse elle-même. Donc on dispose d’un plug-in gérant l’espace de travail (workspace), un autre pour l’environnement graphique (workbench)… Même le noyau d’Eclipse a son propre plug-in. Ainsi pour lancer Eclipse sans interface graphique, il suffit juste de supprimer le plug-in workbench et les autres dépendants de ce dernier.

Workspaces

On appelle workspaces les espaces de travail. Les différents outils introduits dans la plateforme Eclipse interagissant avec les fichiers de l’espace de travail de l’utilisateur. Le workspace regroupe un ensemble de projets qui ont un emplacement propre dans le système de fichiers. Chaque projet regroupe un ensemble de fichiers.
Eclipse introduit un mécanisme de markers qui permet d’associer une valeur à une ressource. Ainsi on peut spécifier la nature d’un projet (projet java, c…). De même on pourra spécifier le compilateur à utiliser pour un type de ressource. Les plug-ins peuvent bien sûr créer de nouveaux markers pour fournir de nouvelles fonctionnalités.
Toutes les opérations sur le workspace sont sauvegardées. Ainsi lors d’une nouvelle session, on retrouvera l’état du workspace comme on l’avait laissé auparavant.

Workbench et UI Toolkits

L’interface utilisateur (UI) de la plateforme Eclipse est gérée par une structure appelée workbench. Cette dernière apporte tous les outils nécessaires à la personnalisation de l’interface utilisateur. L’API du workbench et son implémentation repose sur deux toolkits :
• SWT (Standard Widget Toolkit) est une bibliothèque graphique libre pour Java, créée par IBM. Cette bibliothèque se compose d’une bibliothèque de composants graphiques (texte, label, bouton, panel…), de tous les utilitaires nécessaires pour développer une interface graphique en Java, et d’une implémentation native spécifique à chaque système d’exploitation qui sera utilisée à l’exécution du programme. Par contre son API est entièrement indépendante du système d’exploitation.
• JFace fournit un ensemble de classes pour gérer facilement de nombreuses tâches sur les interfaces graphiques. L’implémentation et l’API de JFace sont indépendants du système de fenêtres graphiques. De plus JFace a été conçu pour fonctionner avec SWT. C’est cet outil qui va gérer toutes les fenêtres, et vues d’Eclipse.
Structure du Plug-In OCAML
Le plug-in ocaml est en fait composé de deux plug-ins distincts. Le premier est commun à toutes les plateformes. C’est le plug-in « ocaml » qui contient toutes les fonctionnalités visuelles du plug-in : éditeur et vues (ocaml browser, console, …). Le deuxième plug-in ocamlCompiler possède plusieurs versions différentes. Ce deuxième plug-in contient le compilateur caml et toutes les librairies standards associées. Il y a donc une version du plugin par plateforme : Windows, Mac et Linux. Une quatrième version a été ajoutée pour les développeurs « confirmés » où il faut définir soit même le chemin du compilateur et des outils utiles pour le fonctionnement du plug-in. Nous avons décidé d’intégrer le compilateur à un plug-in car nous utilisons des options du compilateur qui ne sont apparues qu’à partir de la version 3.07 d’Ocaml. Donc pour éviter des problèmes d’utilisation du plug- in, il nous est apparu évident d’intégrer le compilateur. Ainsi, nous savons quelle version du compilateur Ocaml est utilisée. Par la suite, il a été utile de faire un plugin ne contenant pas de compilateur, mais où il était possible de choisir son propre compilateur.
Les deux plug-in sont donc liés : le plug-in ocaml va chercher tous les chemins d’accès aux librairies ou au compilateur (ou autres outils) dans le plug-in ocamlCompiler via des méthodes spécifiques.
Il est à remarquer que si le plug-in ocamlCompiler sans compilateur est utilisé, il faut que les chemins d’accès ne contiennent pas d’espaces ou de caractères spéciaux.
Par la suite, toute la description se portera sur le plug-in ocaml uniquement. En effet, c’est dans ce plug-in que l’essentiel du travail a été effectué. Le plug-in ocamlCompiler n’est qu’une interface pour obtenir des chemins.

Fonctionnalités du plug-in

Perspective et Vues

Une perspective regroupe un ensemble de fenêtres appelées vues. La perspective ocaml fournit quatre vues :
• OCaml Browser : listage des modules caml disponibles.
• L’éditeur de fichier
• Outline : listage des fonctions définies dans l’éditeur.
• OCaml Console: zone d’affichage de messages.
• Navigator : navigateur de fichiers.
• Problem : regroupe toutes les erreurs de compilation.
Perspective
courante
Éditeur de fichier Outline
Navigateur
de fichiers
Ocaml Console

OCaml Browser

La vue OcamlBrowser est une réplique de l’outil du même nom fourni avec la distribution d’OCaml. La version caml de cet explorateur de modules étant impossible à intégrer sous Eclipse, une version entièrement écrite en java a été développée (voir figure 7). Lors de la création de la vue, on récupère la liste des fichiers d’extension « mli » dans le chemin d’inclusion des librairies ocaml du plugin ocamlCompiler. Ainsi on obtient la liste des modules disponibles. Pour chaque module, on parcourt le contenu du fichier pour récupérer le nom des méthodes associées. Enfin on peut remplir les différents champs de la vue… La liste des modules est la liste des librairies standard de caml. Lors de la sélection du module, le fichier correspondant portant l’extension « mli » est parsé pour récupérer la signature de la méthode, de l’exception ou du type avec le commentaire correspondant. Le graphisme de la fenêtre a été créé entièrement grâce à l’API JFace..

PRESENTATION DU SUJET
DESCRIPTION GENERALE
TRAVAIL A REALISER
OUTILS DE DEVELOPPEMENT POUR OBJECTIVE CAML EXISTANTS
PRESENTATION D’ECLIPSE
LA PLATEFORME ECLIPSE : PRESENTATION TECHNIQUE
LA PLATEFORME RUNTIME ET L’ARICHITECTURE PLUG-INS
WORKSPACES
WORKBENCH ET UI TOOLKITS
STRUCTURE DU PLUG-IN OCAML
FONCTIONNALITES DU PLUG-IN
PERSPECTIVE ET VUES
OCaml Browser
Éditeur de fichiers caml
Outline
OCaml Console
Navigator
Problem
COMPILATEUR
WIZARDS
PREFERENCES ET PROPRIETES
IMPORTATION / EXPORTATION DE PROJETS
FONCTIONNALITES UTILES D’ECLIPSE
AJOUTER UNE FONCTIONNALITE : EXEMPLE DE LA COMPLETION
COMPARAISON DU PLUG-IN V1.0 AU PLUG-IN V2.0
INSTALLATION DU PLUG-IN
METHODOLOGIE ET ORGANISATION DU TRAVAIL
CONCLUSION
BIBLIOGRAPHIE
ANNEXES
GRAPHES DE DEPENDANCE DE CLASSES
OcamlEditor
OcamlBuilder
OcamlBrowserView
OcamlFileProperties et OcamlProjectProperties
Wizards