octobre
2008
Un article de djo.mos
Après avoir été exclusivement une plateforme de développement, ou un EDI (Environnement de développement Intégré), Eclipse s’est transformé au fils des versions en une plateforme pour clients riches (RCP), et est même en train d’être utilisée dans des applications de type serveur, comme par exemple l’utilisation de son conteneur OSGi Equinox comme noyau du serveur SpringSource Spring DM Server.
Cette page liste quelques applications (Opensource et commerciales) développées au dessus d’Eclipse RCP.
Seulement, et du fait qu’Eclipse n’était pas originellement conçu pour ce cas d’utilisation, et que le modèle de développement dans le monde logiciel est hautement dynamique (en terme de besoin et d’objectifs), on peut remarquer que la version actuelle d’Eclipse souffre de quelques problèmes:
- Complexité : C’est un résultat naturel pour l’approche incrémentale qu’a suivi Eclipse. Tous les développeurs le savent (enfin, une portion d’eux du moins): toute fonctionnalité non prévue dans la conception originale rend toute l’application plus complexe et fragile.
Dans le cas d’Eclipse, ça se traduit par un coût d’entrée très élevé (même après une semaine de formation on est toujours à la surface d’Eclipse RCP) à cause d’APIs non uniformes et éparpillées, on a plusieurs méthodes pour faire une même chose, etc. - Apparence : Une application développée avec Eclipse RCP ressemble toujours à l’EDI Eclipse. La plateforme telle qu’elle est actuellement ne permet pas de tout personnaliser et contrôler finement l’aspect graphique
- Footprint : Les applications à base d’Eclipse RCP sont volumineuses (une application vide pèse déjà 13Mo)
- Ainsi que plusieurs autres points plus ou moins techniques/spécifiques (Sécurité, Provisioning, etc.)
Je tiens tout de même à signaler que bien qu’ayant ces défauts, Eclipse RCP reste tout de même une plateforme sur-puissante et offrant un modèle de développement et une infrastructure permettant de développer des applications hautement dynamiques et extensibles.
Pour vous en convaincre, vous n’avez qu’à regarder Eclipse (l’EDI) et la pléthore impressionnante de plug-ins aussi variés et fonctionnels dont il dispose.
C’est ainsi que quelques membres de la communauté Eclipse se sont décidé de prendre à leur charge la planification et conception d’une nouvelle version majeure et révolutionnaire d’Eclipse qui serait ré-écrite à partir de zéro en éliminant les défauts de la version actuelle et en apportant les nouveautés dont Eclipse a besoin pour pouvoir rester une plateforme de développement intéressante.
Ces efforts seront centralisés et cordonnées sous la forme d’un projet (encore en phase d’incubation) nommé E4 (pour Eclipse 4.0, la prochaine version majeure d’Eclipse).
Une liste très loin d’être exhaustive des thèmes de travail de ce projet est:
- IHM déclarative
- SWT et RAP
- La notion de Session, utilisateur, etc.
- La centralisation et uniformisation des services (aka the 20 things :D)
- Divison de la plateforme en composantes client et serveur
- Nouveau modèle pour les ressources (projets, dossiers, fichiers, etc.)
- Les Commandes
- Injection de Dépendances
- Possibilité d’utiliser d’autres langages pour le développement de plug-ins
- Nouveau système centralisé de notifications
- Uniformisation des APIs
- Utilisation de Java 5 dans le noyau d’Eclipse
- etc.
Le travail sur quelques uns de ces thèmes a déjà été entamé et même bien avancé, surtout pour la partie IHM Déclarative.
Je vais donc essayer de vous tenir informés dans des billets futurs des nouveautés et de l’état d’avancement du travail sur E4.
Pingback manuel (attention débat inside)
http://plcoder.net/?doc=2142&rub=0&titre=la-route-de-l-agilite-est-encore-longue