Eclipse Time 2008

Côté outils de développement, la version 3.4 d'Eclipse s'accompagne d'un ensemble de projets à brancher dans la plateforme selon la nécessité : Web Tools 3.0, CDT 5.0, etc. Les projets sont des plugins qui ont été intégrés dans le cycle de développement d'Eclipse. Cela facilite énormément leur recherche et leur installation, garantit leur intercompatibilité et leur non redondance grâce à des releases synchronisées. Au total, la release Ganymède contient 24 projets, dont le noyau Eclipse 3.4 (Callisto contenait 10 projets, et Europa 21).
A noter également la sortie de l'Eclipse Packaging Project 1.0, qui est utilisé pour créer les distributions officielles d'Eclipse (Java SE, Java EE, C/C++, RCP, ...). Ce projet facilite la préparation d'applications basées sur la plateforme Eclipse en choisissant les plug-ins à inclure dans la distribution.

Faire évoluer Eclipse, c'est avant tout faire évoluer le mécanisme de la plateforme. Et on peut dire qu'avec Ganymede, on est servis ! Les projets qui m'ont le plus marqué sont surtout les projets RAP et eRCP : des technologies de runtime de plug-ins Eclipse, tout comme la plateforme RCP classique, à la différence près que RAP est destinée aux serveurs web, et eRCP à l'embarqué ! Le même plug-in peut donc être exécuté sur un poste client, mais aussi sur un serveur web, ou sur un terminal mobile, sans changer une seule ligne de code, sans même le recompiler !
Le projet RAP m'a particulièrement intrigué. Il est basé sur une implémentation "parallèle" de SWT/JFace, qui fait appel à des mécanismes autant sur le serveur que sur le navigateur web. Côté serveur on retrouve l'implémentation de la norme OSGI par Eclipse : Equinox. Côté client, c'est qooxdoo, une librairie JavaScript et AJAX, qui implémente l'interface graphique et les communications.

Dans le but simple d'augmenter le nombre de développeurs sous Eclipse, beaucoup d'initiatives, quelques unes évidentes, d'autres surprenantes, ambitieuses, voire même déroutantes sont au programme.

Faciliter la prise en main : l'API de développement de plug-ins est difficile à prendre en main, et plusieurs axes d'amélioration ont été identifiés : l'accès aux APIs et la documentation doivent être relevés, et il faut éviter les APIs redondantes.
Séparer la présentation du contenu : on pourrait être satisfait de SWT et JFace, les APIs graphiques utilisées par Eclipse. Mais il est prévu d'inclure la gestion de scripts et de styles dans la plateforme, de manière à fournir des interfaces plus facilement modifiables (à la fois en phase de développement et au runtime). Ceci ferait intervenir un (des?) langage(s) de description d'IHM, probablement basé(s) sur du XML (XUL, XAML, ...) voire du CSS.
Faire évoluer OSGi : les évolutions les plus radicales concerneront la plateforme elle-même. Dans le but de rallier plus de monde à la communauté, il est prévu de permettre le développement de plug-ins dans d'autres langages que le Java ! Dans l'absolu, une fois ce but atteint, on peut même imaginer que le noyau de la plateforme soit lui-même écrit dans un autre langage. Cette évolution est très ambitieuse, et laisse entrevoir une plateforme où des plug-ins écrits dans des langages divers communiqueraient entre eux. A suivre, donc !

Pour faire d'Eclipse une véritable plateforme d'applications, un exemple des mesures qui seront prises est de ne plus nécessairement inclure les concepts de projets et de perspectives dans le noyau de la plateforme. En effet, ce sont des notions qui ne sont pas nécessaires à toute application. Aussi, le noyau de la plateforme sera le plus générique possible, tout en continuant à offrir les mécanismes qui rendent cette même plateforme attrayante.

L'intégration des plug-ins a déjà évolué afin de gérer des dépendances complexes entre les plug-ins. Elle doit encore muter afin de proposer une approche par services. Cela permet de ne pas s'intéresser au contenu du plug-in, mais simplement à ses fonctionnalités. Outre le gain pour l'utilisateur qui n'a pas à s'occuper de pures problématiques d'implémentation qui ne l'intéressent pas directement; à terme, cela offre aux développeurs de plug-ins les moyens de mettre en place des interactions plus fortes et plus complexes entre les plug-ins.
Le développement de plug-ins doit être facilité par l'utilisation du framework EMF pour mettre en oeuvre un véritable modèle de la plateforme Eclipse.

Les implémentations Web et mobile de la plateforme Eclipse (respectivement, RAP et eRCP) sont promises à un développement rapide. Pour RAP, des supports différents de AJAX sont envisagés : Dojo, Flex, Silverlight, etc. On attend SWT 4, qui harmonisera les interfaces graphiques sur tous les supports, et facilitera la portabilité des applications.
eRCP est lui aussi un élément important, puisqu'il permet d'embarquer une application Eclipse de manière totalement transparente. Le secteur de la production industrielle est ouvertement visé par la stratégie de développement.