IV. LE TRAVAIL EFFECTUE : ENVIRONNEMENT DE DEVELOPPEMENT.

1. CONTEXTE

Au début du stage, l’équipe utilisait des outils de développement disparates et spécifiques à chaque développeur (à ce sujet voir l'Annexe II, et particulièrement le chapitre 2. Logiciels et technologies utilisés). Un effort avait été initié dans le but d’homogénéiser le travail, ce qui a abouti à la définition d’une norme définissant Les préconisations de développement. Les outils de développement, par contre, restaient très différents selon les développeurs.

Utilisateur d’eclipse, j’ai proposé que cet outil devienne l’outil standard de l’équipe.

2. DESCRIPTION D’ECLIPSE

Eclipse est souvent présenté comme un environnement de développement, mais c’est à la fois plus et moins que cela. C’est en fait un « framework » d’applications, un cadre où d’autres applications vont venir s’intégrer. Eclipse n’est donc pas un environnement de développement, mais un conteneur pour environnement de développement - bien qu’en réalité il puisse contenir autre chose.

2.1. La plate-forme eclipse

La plate-forme définit donc un ensemble de frameworks et de services communs pour assurer une interopérabilité des outils qui se rajoutent par dessus (les plug-ins). C’est l’équivalent d’un noyau pour un système d’exploitation. Elle comprend un système de gestion concurrente de ressources distribuées (Versioning and Configuration Management), une gestion de modèle de projets, une gestion automatique des deltas entre versions pour les compilations incrémentales, une infrastructure de deboggage indépendante des langages de développement, un framework d’extension des fonctionnalités par des plug-ins, une bibliothèque graphique portable (Standard Widget Toolkit, SWT), un framework pour une interface graphique portable (JFace), un système générique d’aide, de recherche, de comparaison, de mise à jour des plug-ins, des parseurs, l’intégration de Jakarta Ant, le support de scripts, etc. La Figure 10 présente l'architecture d'eclipse.

l'architecture d'eclipse
Figure 10 - l'architecture d'eclipse

Eclipse est entièrement codée en java, à l’exception d’une dll de 232ko sous Windows qui est codée en C : la dll de SWT. La machine virtuelle Java est changeable à souhait, à partir des versions 1.3 pour une fonctionnalité totale.

2.2. Les plug-ins

Un autre intérêt majeur de la plate-forme réside dans son architecture de plug-ins. Pour mieux comprendre sa maturité, il faut détailler les différents niveaux d’intégration offerts pour un plug-in :

  1. Invocation : un double-click appelle la cible
  2. Intégration des données : permet à des plug-ins d’accéder à des données qui viennent d’être créées par d’autres plug-ins
  3. API : l’ajout d’un plug-in sur le système rajoute des nouveaux comportements à des plug-ins déjà installés. On n’accède plus à des données comme précédemment, on réutilise un comportement.
  4. Framework d'interface graphique : permet de construire une interface utilisateur

La découverte et la mise à jour des nouveaux plug-ins est dynamique. Mieux, les plug-ins peuvent eux-mêmes comporter des points d’extensions, et supporter leurs propres plugins, lesquels peuvent utiliser tous les services de la Plate-forme.

2.3. L’environnement graphique

L’ergonomie générale d’eclipse est organisée en perspectives. Il s’agit de fenêtres rassemblant des options autour d’un thème commun. La navigation dans eclipse est complètement personnalisable : emplacement, présence, taille, empilement des panels (sous-fenêtres), options présentes. Cette versatilité peut dérouter au début, mais permet à tous les développeurs, quelles que soient leurs habitudes, de construire une ergonomie qui leur convienne. La Figure 11 présente un exemple d’- Environnement graphique d'eclipse : la perspective d’édition PHP de PHPEclipse.

3. DEROULEMENT DE L’ETUDE

L’étude a consisté en la préparation d’un environnement eclipse pré configuré et disposant de tous les plug-ins utiles au développement au sein de l’équipe. Il a fallu pour cela étudier les différents plug-ins proposés pour chaque tâche, voire même en modifier certains afin de les adapter aux contraintes des outils et logiciels de l’équipe.

3.1. Plug-ins retenus

Les plug-ins additionnels retenus sont :

Du fait du caractère Open Source de ces plug-ins, il a été facile d’effectuer les modifications nécessaires à leur intégration dans l’environnement de l’équipe. Citons par exemple la modification du plug-in Sybase de JfaceDbc, modifié pour reconnaître le serveur Sybase utilisé dans les développements.

De même, le plug-in CVS, intégré dans la distribution eclipse par défaut, a du être modifié afin de pouvoir créer des versions compatibles avec l’interface d’administration CVS du framework.

4. INTERPRETATION ET CRITIQUE DES RESULTATS

L’étude a été concluante, et l’outil adopté par la majorité de l’équipe. Un package permettant un déploiement rapide a été créé, accompagné d’un certain nombre d’additions (fichiers de configuration, base de templates de prototypes PHP, plug-ins supplémentaires, etc.).

De plus une documentation a été écrite afin de présenter l’outil, les différents plug-ins, et aussi les modifications faites dans le code pour pouvoir effectuer de la maintenance évolutive, ou de suivre les mises à jour d’eclipse sans perdre les fonctionnalités liées à des spécificités internes.

Il ne reste qu’un point noir : la gestion des procédures stockées dans les bases de données Sybase, qui soufrent d’un bug empêchant de recevoir autre chose que le résultat de la première opération effectuée dans la procédure.