Trucs, Astuces et Bonnes Pratiques avec Eclipse
Publié le 25 août 2012 et mis à jour le 10 octobre 2012
Par
Laurent Barbareau
Dans cet article, je présente entre autres, ma manière d'utiliser cet EDI qu'est Eclipse. Je passe donc en revue certains des réglages que j'applique, les pièges à éviter,
quelques bonnes pratiques, les astuces pour augmenter sa productivité, ainsi que certaines des fonctionnalités moins connues mais que j'estime utiles.
Pour sa rédaction, je me suis basé sur mon expérience d'un peu moins d'une décénie d'utilisation d'Eclipse mais aussi
sur les discussions du forum Eclipse dont je suis un des modérateurs depuis 2009, ainsi que ce que l'on peut retrouver parfois dans la FAQ Eclipse.
Cet article relate ma propre expérience par rapport à Eclipse. Il n'est donc pas impossible que celui-ci vous paraisse par moment un peu partial mais l'important à mon sens est que
vous puissiez y "faire votre marché".
Ainsi, vous aurez tout loisir d'appliquer ce qui vous semble intéressant, de critiquer ce sur quoi vous n'êtes pas d'accord et de proposer éventuellement des alternatives plus efficaces,
via le forum.
J'ajoute que cet article s'adresse davantage aux personnes qui connaissent déjà un minimum Eclipse car ça n'a rien d'un tutoriel classique et c'est sans doute plus proche d'un livre de recettes.
I. Installation d'Eclipse
I-A. Pré-requis
I-B. Installer Eclipse
I-C. Eclipse et Java
I-D. Les différences selon les Systèmes d'Exploitation (S.E.)
I-E. 32 ou 64 bits ?
I-F. Gérer plusieurs JRE avec Eclipse
I-G. Les informations d'exécution d'Eclipse
I-H. Choix d'emplacements sur le disque
I-I. Nom du répertoire d'Eclipse
I-J. Nom et organisation des workspaces
I-K. Paramètres liés aux workspaces
I. Installation d'Eclipse
Avant de rentrer dans le vif du sujet, même si cet article s'adresse plutôt aux personnes qui savent déjà manipuler Eclipse, nous allons passer en revue certains points
permettant de s'assurer d'une installation pérenne d'Eclipse.
I-A. Pré-requis
Note :
Même si vous n'utilisez pas Eclipse pour développer en Java, vous devez tout de même avoir à l'esprit que cet EDI est développé en Java (dans sa quasi totalité).
De fait, pour pouvoir s'exécuter il a besoin d'une machine virutelle Java, autrement dit une JVM (Java Virtual Machine).
Cette JVM est fournie par un environnement d'exécution Java, nommé JRE (Java Runtime Environnement) qui constitue l'ensemble des composants de base pour l'exécution de code Java compilé.
Si vous ne développez pas en langage Java avec Eclipse, un JRE est suffisant.
En revanche, si vous développez en Java, vous devez savoir que pour des questions pratiques, un JDK (Java Development Kit) est préférable.
Un JDK contenant obligatoirement un JRE, il n'est pas utile d'installer à la fois un JDK et un JRE.
Tout d'abord, il faut avoir en tête les éléments suivants :
I-B. Installer Eclipse
De base, Eclipse n'est pas founi avec un programme d'installation. Ainsi, il faut récupérer un fichier compressé en .zip ou .tar.gz,
à partir du site
http://www.eclipse.org/downloads/, puis décompresser simplement le fichier récupéré, à un endroit approprié.
Cette particularité peut être déroutante car généralement on a l'habitude de disposer d'un exécutable qui se charge d'installer le programme que l'on souhaite. Voire, de faire enventuellement
appel au gestionnaire du programmes du système, pour effectuer sa désinstallation.
Pour Eclipse, le choix a été fait de ne fournir qu'un fichier compressé car finalement, dans son cas, le rôle d'un programme d'installation
se cantonnerait à décompresser le fichier à un endroit indiqué.
Donc, si Eclipse n'a pas de programme d'installation c'est aussi parce qu'il est autonome (en dehors de la nécessité de disposer d'une JVM) et ne déclare rien
au niveau des registres du Système d'Exploitation sur lequel il est installé.
Par exemple, vous pouvez exécuter Eclipse, le fermer, déplacer son repertoire d'installation, puis le relancer, sans que cela ne pose de problème.
I-C. Eclipse et Java
Bien qu'étant décorrélé au maximum du Système d'Exploitation sur lequel il est installé, Eclipse requiert impérativement la présence d'une JVM (Java Virtual Machine).
Cette dernière est disponible à partir du moment où un JRE (Java Runtime Environnement) est installé sur le système.
La version de JRE nécessaire à Eclipse dépend bien évidemment de la version de ce dernier. Habituellement, il n'exige pas de disposer de la dernière version de JRE disponible.
Pour les versions récentes d'Eclipse, c'est la version de JRE 6 qui est recommandée. Les JRE ayant une compatibilité ascendante, une version ancienne d'Eclipse qui n'exigeait
que la version 1.4.2 par exemple, devrait fonctionner parfaitement sur un JRE 5, 6 ou 7.
A savoir que chacun des plug-ins installés sur Eclipse est en droit d'exiger une version majeure spécifique de JRE pour fonctionner. De fait, il est sans doute préférable d'utiliser
un JRE dans une version relativement récente.
Il arrive également que certaines révisions de JRE soient buggées, provoquant des dysfonctionnements dans Eclipse. Alors parfois, il peut être nécessaire de s'assurer d'avoir une révision
de JRE plus récente, ou plus ancienne si la dernière en date est justement à l'origine du problème.
I-D. Les différences selon les Systèmes d'Exploitation (S.E.)
La grande majorité du code d'Eclipse est développée en Java, ce qui lui permet théoriquement de pouvoir s'exécuter sur n'importe quel système sur lequel une JVM conforme aux pré-requis,
est présente. Toutefois, comme il utilise sa propre librairie graphique (SWT) pour la partie IHM et que le rendu est dépendant de ce que permet le système hôte, il faut potentiellement
s'attendre à d'éventuelles variations de présentation ou de comportement. Généralement ça n'a rien de très problématique mais il n'est pas rare en revanche que sur certains systèmes,
selon le gestionnaire graphique installé, il y ait des bugs d'affichage (notamment sous Linux avec les variantes de couches IHM).
Dans ce cas, il faut s'assurer de disposer des composants du système les mieux adaptés, en faisant éventuellement quelques recherches.
I-E. 32 ou 64 bits ?
Depuis l'apparition relativement récente des processeurs et systèmes d'exploitation 64 bits, Eclipse est fourni également dans des versions dédiées à ce mode de fonctionnement.
Ainsi, s'il on veut pouvoir en profiter pleinement, il est important de se procurer des versions de JRE et d'Eclipse prévues pour le mode 64 bits.
Le JRE et Eclipse doivent toujours être dans le même mode de fonctionnement. En revanche, a priori il reste possible d'exécuter Eclipse en mode 32 bits alors que le système d'exploitation
fonctionne en 64 bits, du moment que le JRE fonctionne également en 32 bits.
I-F. Gérer plusieurs JRE avec Eclipse
Dans un environnement de développement, il est fréquent d'utiliser en parallèle différentes versions de JRE / JDK. Le problème peut alors survenir de savoir sur quelle version Eclipse va-t-il
s'exécuter ?
Sauf paramétragre contraire, c'est le premier java.exe ou javaw.exe trouvé via la variable d'environnement PATH qui servira à exécuter Eclipse. Ceci peut donc poser quelques problèmes et il
est alors préférable de s'assurer qu'Eclipse démarre sur le bon JRE.
Pour cela, vous avez les indications nécessaires, disponibles ici
Comment lancer Eclipse avec une autre JVM que celle
par défaut ?. En résumé, s'il on veut éviter les conflits au niveau du PATH et déterminer explicitement quel JRE utiliser pour Eclipse, il faut préciser directement à Eclipse sur quel JRE
démarrer.
I-G. Les informations d'exécution d'Eclipse
Lorsqu'Eclipse est démarré, il est possible de connaître l'environnement à partir duquel il s'exécute et potentiellement de vérifier que les paramétrages spécifiques sont bien pris en comptes.
Pour cela, il suffit d'aller dans le menu Help > About Eclipse, de cliquer sur le bouton Installation Details, puis de sélection l'onglet Configuration.
On obtient ainsi l'ensemble du contexte de l'environnement d'exécution d'Eclipse.
I-H. Choix d'emplacements sur le disque
Sous Windows en particulier, il est important de prendre soin d'installer Eclipse à un endroit proche de la racine.
Par exemple, le répertoire "c:\Program Files" convient assez bien, en revanche l'installer dans un répertoire du style
"c:\Documents and Settings\user_toto\Téléchargement\dev\Eclipse" est plutôt à éviter.
Windows étant assez vite limité au niveau du nombre de caractères acceptés dans les chemins, de par son Système de Fichiers, qu'en ne prenant pas garde à cette contrainte
vous risquez de vous retrouver confronté à ce problème à un moment donné, sans doute en mettant un peu de temps à réaliser d'où il vient.
Cela n'est pas propre à Eclipse evidemment mais comme tous les plug-ins sont nommés en fonction des packages (cf. le répertoire plugins d'Eclipse), sous Windows, il est relativement
facile d'atteindre ses limites.
Cette précaution est tout autant, voire davantage, applicable aux emplacements de vos workspaces. Par exemple, le développement d'un projet à base de plug-ins OSGi
et s'appuyant sur Maven, pourra très rapidement être confronté à cette problématique (constatation personnelle). Cela est dû notamment à la multitude de dépendances
inter-plugins que l'on peut avoir, provoquant une augmentation conséquente de la taille de la ligne de commande, lors de l'exécution. Dans ce cas précis, au-delà
de la limite du nombre de caractères dans un chemin, il s'agit en fait d'éviter d'atteindre trop rapidement la limite du nombre de caractères acceptés par une commande,
de par la consitution d'un CLASSPATH gigantesque.
Ceci reste certainement assez typique des problèmes liés au formalisme verbeux employé en programmation Java. Cependant, dans la mesure du possible, il convient de placer Eclipse
et son ou ses workspaces à des endroits proches de la racine d'un disque. Evidemment, cela ne garantit rien car il est toujours possible d'atteindre les limites quoi
que l'on fasse mais en adoptant ce principe on a plus de chance d'éviter ce genre de problèmes purement techniques.
I-I. Nom du répertoire d'Eclipse
De par sa conception entièrement modulaire, sa nature Open Source, son rythme de mise à jour et la structure de l'équipe qui le développe, Eclipse a constamment évolué depuis sa création.
Un tel projet est bien évidemment complexe à gérer et cette évolution n'a jamais été sans heurt, il faut bien le reconnaître. Chaque changement de version apporte son lot
de nouveautés mais aussi, inévitablement quelques nouveaux bugs. Eclipse est pourtant soumis à des tests mais à moins que vous soyez tout nouveau développeur, il est inutile
de vous rappeler que n'importe quel développement logiciel n'est jamais parfait. Eclipse ne peut donc pas se soustraire à cette "règle" (pas plus et pas moins que les autres EDI de toute façon).
De fait, sans doute vaut-il mieux l'accepter et tenter de se prémunir autant que possible, de certains désagréments.
Pour cela, j'ai notamment pris l'habitude d'installer une nouvelle version à côté de l'ancienne. De fait, à chaque version que je récupère, je décompresse le zip et de suite après je le renomme en fonction
de plusieurs critères. En particulier, j'ajoute toujours le numéro de version et aussi un identifiant permettant d'indiquer de quel package Eclipse il s'agit.
Concrètement, voici un exemple de ce à quoi peut ressembler un répertoire Program Files sous Windows, par rapport aux différentes versions d'Eclipse :
...
/eclipse-3.5-jee
/eclipse-3.5.2-jee
/eclipse-3.6-rcp
/eclipse-3.7.1-java
...
|
Libre à vous de choisir une règle de nommage qui vous convienne le mieux. Quoi qu'il arrive, comme expliqué précédemment, les renommer ultérieurement n'est pas censé être problématique.
Peut-être vous posez-vous la question de savoir pourquoi intérêt y a-t-il à conserver toutes ces versions ? La réponse est que parfois c'est une nécessité et d'autres fois ce sera
de la simple prudence. Comme expliqué précedemment, Eclipse n'est pas en mesure de gérer tous les cas délicats. Il est soumis à des mécanismes assez complexes de gestion des
dépendances, des plug-ins qui le composent. Ainsi, malgré les progrés accomplis dans ce domaine, il demeure difficile de déployer sans crainte une nouvelle version.
C'est pourquoi, dans bien des cas, il peut être nécessaire de systématiquement installer une nouvelle version, à côté de l'ancienne et ce, même si la version majeur est la même.
Autrement dit, par prudence, on préférera installer un Eclipse 3.7.1 à côté d'un Eclipse 3.7, avant de décider de se passer de la 3.7 et de la supprimer. Donc, bien qu'il soit
possible de faire une mise à jour, de la 3.7 à la 3.7.1 (par exemple), directement à partir du gestionnaire de mises à jour intégré à Eclipse, il est relativement plus
prudent d'installer la nouvelle version à côté.
Certes, il sera peut-être nécessaire de réinstaller tous les plugins que vous aurez ajouté à un package Eclipse de base mais cela peut parfois permettre de débloquer certains problèmes.
Egalement, l'installation d'une version d'Eclipse par-dessus une autre, est une opération hasardeuse qu'il convient de ne pas tenter si vous préférez éviter les problèmes.
Différents paramètres peuvent entrer en jeu dans ce genre de problème. Cela peut être plus ou moins lié au package Eclipse que vous avez choisi d'installer mais aussi au plug-ins
que vous avez ajoutés par la suite, ou encore au fait que certains plug-ins ne peuvent tout simplement pas avoir 2 versions coexistantes...
Dans certains cas, vous êtes également obligé de conserver une ancienne version car un des plug-ins Eclipse que vous utilisez ne fonctionne pas sur une version trop récente. De surcroît et
d'une manière générale, il peut même être utile d'installer plusieurs fois la même version d'Eclipse, pour des usages différents. Cela peut s'avérer nécessaire mais surtout,
empiler tous les plug-ins, sur une même installation d'Eclipse, est une très mauvaise idée. On l'a vu, certaines contraintes font que la coexistence n'est pas toujours possible entre
les plug-ins, les raccourcis claviers peuvent également devenir problématiques lorsqu'ils ont un rayon d'action trop large ou mal délimité, certains plug-ins font même doublon et peuvent interférer
entre eux. Donc, il faut bien considérer une chose, même si la gestion des plug-ins est censée faire son maximum pour que les dépendances soient honorées et que lorsque les dépendances
ne peuvent l'être, les plug-ins concernés ne sont pas installés ou activés, il reste néanmoins des cas où il est évident que l'on ne peut pas tout conscillier. Donc, un principe
de base avec Eclipse qu'il vaut toujours mieux n'installer que les plug-ins dont on a besoin pour son activité donnée. Ceux qui ont déjà tenté l'installation complète de tous les plug-ins disponibles
(ce fut mon cas personnel au début), ont certainement vite compris que ça ne servait strictement à rien du tout.
Ainsi, on peut reprocher un certain nombre de problèmes lors de l'utilisation d'Eclipse mais côté installation, on voit bien qu'il tire largement son épingle du jeu, notamment en autorisant
de multiples installations, de par son autosuffisance et en ne polluant pas les registres du système avec des références.
Egalement, bien que vous puissiez théoriquement mettre à jour une version mineure d'Eclipse, sur une version majeure, en cas de problème, sans doute vaut-il mieux ne pas hésiter à
faire une réinstallation toute propre d'Eclipse. Le forum peut d'ailleurs témoigner d'un certain nombre de difficultés rencontrées, lors de la mise à jour d'Eclipse, ce qui se solde assez
souvent par une réinstallation d'Eclipse.
I-J. Nom et organisation des workspaces
Pour ce qui est des workspaces, là aussi il faut penser à des nommages intelligents des répertoires.
Rappelons ce qu'est un workspace :
Physiquement, un workspace est un répertoire sur le disque, qui va servir à la fois à enregistrer des configurations de contexte, des configurations de plug-ins, des traces du fonctionnement
d'Eclipse, de référencer les projets du workspace et aussi de conserver l'historique des modifications des fichiers source.
De base, un répertoire de workspace ne contient qu'un répertoire .metadata, lequel contient une arborescence qui ressemble à ceci :
Pour étudier ce qui se passe dans un répertoire de workspace, vous pouvez vous amuser à en créer un, sans autre action que d'indiquer à Eclipse sur quel workspace il doit démarrer.
Pour cela vous avez le choix, soit vous allez en ligne de commande, vous vous placez dans le répertoire d'Eclipse et vous exécutez la commande eclipse -data c:\dev\monnouveauworkspace, soit
vous prenez un raccourci existant qui vous permet de démarrer Eclipse, vous le dupliquez et ensuite vous le modifiez (via un
clic droit > Propriétés
en général) et vous ajoutez
-data c:\dev\monnouveauworkspace, à la suite de la commande ciblée. Vous lancez Eclipse et celui-ci démarrera en utilisant le workspace indiqué, alors même que vous
n'avez pas créé l'arborscence spécifiée !
A l'instar de la mutiplicité des instances et versions d'Eclipse que vous pouvez avoir, vous avez intérêt à multiplier également vos workspaces, en fonction de vos activités. Ainsi,
il vous faut penser à nommer chacun d'eux intelligemment.
Il convient tout d'abord, de nommer un workspace en fonction de l'instance d'Eclipse avec laquelle vous l'utilisez. Pour cela, vous pouvez vous inspirer de la façon de nommer les répertoires
d'Eclipse. A titre d'exemple, vous pouvez avoir workspace-eclipse-3.5.2-jee mais comme parfois il peut s'avérer important d'économiser le nombre de caractères (surtout sous Windows),
n'hésitez pas à adopter un nom plus court. Ensuite, vous devez avoir à l'esprit qu'il est important, pour des raisons quasi évidentes lorsque l'on observe le contenu d'un répertoire
.metadata d'un workspace, de le dédier à une seule instance d'Eclipse. Pour avoir testé personnellement l'utilisation simultanée d'un même workspace par deux versions
différentes d'Eclipse, je sais que ça fonctionne tant bien que mal mais lorsque ça se bloquait un certain temps et qu'il fallait que j'arrête l'un des deux, je me doutais bien de ce
qu'il pouvait y avoir comme problème. Il n'en demeure pas moins que cette façon de faire reste hasardeuse et est parfaitement déconseillée.
Quand on connaît un peu mieux Eclipse, on réalise que ce genre de tentative est rarement nécessaire et que même en cas de besoin d'utiliser 2 versions d'Eclipse pour un même projet,
la solution du partage de workspace est quasiment une hérésie. Dans ce genre de situation, ce n'est pas le workspace qu'il faut partager mais les projets.
La différence est que chaque workspace étant en principe dédié à une version d'Eclipse (souvenons-nous qu'il y est stocké des paramètres et que de plus, ceux-ci ne sont pas forcément
compatibles d'une version à une autre), celles-ci doivent en rester les uniques utilisateurs. De plus, rien n'oblige normalement à placer tous ses projets dans le répertoire même du workspace.
Le principal étant qu'ils y soient référencés. Autrement dit, un projet est référencé par un workspace à partir du moment où vous pouvez le voir dans l'Explorateur de projets d'Eclipse
Il est important de savoir cela car ça permet de s'organiser plus facilement, lorsque par exemple on utilise un gestionnaire de versions de sources tel que CVS, SVN, ClearCase...
Et de fait, comme on est libre de placer ses sources où l'on veut, plusieurs workspaces peuvent référencer les mêmes projets, notamment par la fonction
File > Import > General > Existing Projects into Workspace.
I-K. Paramètres liés aux workspaces
On l'a vu, les workspaces contiennent un ensemble de paramètres, notamment les configurations d'environnement. De fait, partir d'un workspace complètement neuf à chaque fois,
peut vous obliger à reconfigurer un certain nombre de paramètres, ce qui prend toujours un peu de temps si on le fait à la main.
Heureusement, il existe différentes façons de se faciliter la tâche, surtout si on travaille en équipe et qu'il est nécessaire d'adopter un paramétrage commun.
Par exemple, on peut élaborer un paramétrage de workspace, en en créant un nouveau, dans lequel on ne configure que le strict nécessaire, sans même ajouter de projet.
Une fois qu'on estime celui-ci conforme à ce que l'on veut, on ferme Eclipse et on zippe le répetoire du workspace, que l'on conserve et que l'on pourra réutiliser ultérieurement.
On peut très bien le mettre à disposition sur un répertoire partagé, ou le déposer sur un serveur équipé d'un système de gestion des versions (CVS, SVN, Git...).
Cette façon de faire est très efficace, elle permet de configurer rapidement un environnement. De plus, il est bien évidemment possible de mettre à jour le workspace sauvegardé, en
fonction des nouveaux besoins qui pourraient se présenter. Il faut simplement faire attention à rester minimaliste dans votre paramétrage. Avant de zipper le workspace, vous pouvez faire
un peu de ménage à l'intérieur, notamment supprimer les éventuels fichiers .log, lock et tout ce qui vous semble inutile.
Une autre manière de faire, consiste à exporter et importer ses paramètres, de manière classique, via le menu File > Import... > General > Preferences.
Copyright © 2012 Laurent Barbareau.
Aucune reproduction, même partielle, ne peut être faite
de ce site ni de l'ensemble de son contenu : textes, documents, images, etc.
sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à
trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.
