Actualités

10 conseils pour travailler en équipe avec Eclipse

Vous travaillez en équipe avec Eclipse et vous n’arrivez pas toujours à vous y retrouver entre tous les postes de vos développeurs ? L’installation d’un nouveau poste vous prend du temps ? Vous vous posez des questions sur votre organisation de travail ? Vous pensez que vous pourriez améliorer les choses ?

Cet article vous donnera 10 conseils pour vous guider dans l’uniformisation de vos postes de développement.

1. Installation d’Eclipse

Pour bien développer, il est indispensable d’utiliser la dernière version d’Eclipse disponible. Cette version se télécharge sur le site d’Eclipse : https://www.eclipse.org/downloads/

Si la version d’Eclipse téléchargée n’est pas suffisante (par exemple un eclipse modeling, ne contient pas les webtools, ou svn), il faudra gérer les outils ajoutés. Plusieurs manières de faire sont possibles :

  • lister dans un wiki, les updates sites des outils complémentaires à installer et diffuser l’information
  • installer les compléments dans un Eclipse fraichement téléchargé, et faire installer cette version (gérer les différentes plateformes s’il y a des développeurs sur windows/linux, etc…)
  • proposer un update site interne, regroupant tous les outils à installer

Dans tous les cas, il faut s’assurer que chaque développeur travaille bien avec les mêmes versions d’outils.

2. Gestion du workspace

Eclipse gère les projets dans un workspace auquel sont associés des paramètres appelés préférences.

Chaque projet ayant des caractéristiques différentes selon les clients, il faut gérer un workspace par projet.

Dans le cas de développement sur des branches de maintenance, on utilisera également un workspace dédié pour cette branche.

On passera d’un workspace à l’autre en utilisant la commande ‘File->Switch Workspace…’.

On pourra recopier les préférences d’un workspace à l’autre lors de la création d’un nouveau workspace, ou importer des préférences stockées dans un fichier une fois le workspace créé.

3. Réglages Java

Dans un environnement multi développeurs, les machines et les configurations java sont souvent différentes. Pour éviter les problèmes de configuration, il convient, dès le départ, de bien régler certains paramètres.

Les environnements Java permettent de faire correspondre une version de Java (J2SE-1.5 par exemple) à un JRE ou un JDK installé sur votre machine. Ces environnements sont stockés dans le workspace courant.  C’est un des rares réglages manuels à faire sur chaque poste de travail, les autres pouvant être partagés en sauvant les préférences (Cf §5) :

 

Dans les projets java ensuite (pour les plugins, on ne peut choisir que des environnements), seuls les environnements java doivent être utilisés et référencés. Il ne faut plus utiliser la JRE courante ou un JRE alternatif :

Ainsi, si un développeur récupère un projet par la gestion de configuration et qu’il dispose par défaut d’un JDK 1.5, son projet sera en erreur et il devra régler ses préférences correctement.

4. Formattage du code

Autre réglage important : les règles de formatage de code, qu’il est nécessaire de partager entre tous les développeurs. Si on ne les fixe pas dès le départ, et que les fichiers sont ensuite livrés en gestion de configuration, cela va poser des problèmes lors des comparaisons avec les versions antérieures.
Le réglage, pour java, se fait dans les pages de préférences et l’idéal est d’importer un fichier de préférences commun, propre au projet et partagé sur le réseau (obtenu la première fois en faisant un export all) :

 

On peut notamment modifier la taille de ligne par défaut qui est fixée à 80 colonnes et qui est maintenant inadaptée vu la taille des écrans !

5. Partage des préférences du workspace

En exportant les préférences du workspace (Menu Export → Préférences), il est possible et simple de partager les préférences communes d’un projet. Le fichier .epf créé peut ensuite être réimporté sur les autres postes.

6. Commit des fichiers de gestion d’Eclipse

Eclipse stocke dans le répertoire du projet quelques fichiers de configuration nécessaires à son fonctionnement. On trouve notamment :

  • le fichier .project contenant les informations du projet
  • le .classpath si le projet est de nature java
  • le .cproject si le projet est en C/C++
  • le répertoire .settings contenant les propriétés des ressources.

Ces fichiers doivent être commités dans la gestion de configuration afin de les retrouver sur chaque poste de développement.

 

7. Partage des configurations de lancement

 

Quelque soit le type de projet, les paramètres de lancement d’une ‘launch configuration’ peuvent se stocker dans un fichier. On accède au partage, dans l’onglet ‘Common’ de chaque launch configuration. Un fichier ‘.launch’, se stocke dans le projet et peut être commité dans la gestion de configuration. En sélectionnant les menu Run et Debug, les autres développeurs pourront y accéder directement dans les menus.

8. Gestion de la target platform

Lors du développement d’une application RCP, il est nécessaire de fixer la target plateform du workspace.

Le mieux est de créer un fichier target (New Wizard → target Definition), dans le plugin principal de l’application. Bien sur ce fichier sera stocké dans la gestion de configuration (cvs, svn…).

Pour permettre l’utilisation commune des fichiers target, il ne faut pas référencer des fichiers en local, mais plutôt référencer directement les sites Eclipse, ou éventuellement un répertoire partagé accessible.

L’écran de préférences de target platform référence ensuite tous les fichiers .target présents dans le workspace :

9. Utilisation des ‘working sets’

Le workspace peut rapidement contenir plusieurs projets, voire plusieurs dizaines de projets. Les ‘working sets’ vont permettre de ranger le workspace en créant des groupes pour rassembler les projets. Un projet peut appartenir à plusieurs ‘working sets’ simultanément.

L’affichage en mode working set, s’effectue dans le menu de la vue package Explorer :

 

Ce même menu contient aussi les commandes permettant de remplir les working set avec les projets .

10. Export du workspace pour le partager

Enfin, une fois que le workspace est bien rangé avec les ‘working sets’, il est possible d’exporter son contenu dans un fichier ‘Team Project Set’. Ce fichier contient toutes les URL d’accès à votre gestionnaire de configuration (cvs, svn, …), mais aussi tous les ‘working sets’ définis.

Il suffit qu’une personne définisse un workspace de référence, contenant tous les projets, rangés par working set, et qu’elle exporte ce workspace dans un fichier stocké sur un disque partagé :

 

Un nouveau développeur, peut alors installer un nouveau poste en 3 étapes :

  • installer un Eclipse avec ses outils
  • importer les préférences communes
  • importer le fichier team project set du projet

 

Commentaires Utilisateurs


  1. OPCoach
    19 février 2012

    Effectivement toutes les préférences ne sont pas toujours exportées et dans ce cas, l’astuce est de les rendre project specific.
    Pour recopier les propriétés, le copie du répertoire .settings d’un autre projet doit être un bon début avant de tout revérifier.


  2. Jérémie
    19 février 2012

    Nous on met énormément de choses dans les réglages project specific de chaque projet eclipse (convension Java, checkstyle, …), plutôt que dans les préférences du workspace.

    Inconvenient:
    – Lors de la creation d’un nouveau plug-in / fragment il faut aller copier “à la main” les réglages fait dans les autres projets.

    Avantage:
    – certaines choses ne marchent pas avec la méthode décrite au point §5 (par exemple: avant on avait toujours besoin de réimporter les réglages de checkstyle à la main).


  3. Jérémie
    19 février 2012

    D’après ce que j’ai compris, Maven permet de stocker un certain nombre de conventions pour que tous les développeurs d’un projet utilisent les même.
    Cela fait doublon avec les réglages d’Eclipse (project specific). Certainement aussi avec les autres IDE (je ne sais pas comment cela est résolu).

    Du coup il faut se poser la question de faire les choses:
    – à la manière Maven.
    – à la manière Eclipse.

    Il me semble que c’est un des buts de Tycho de faire converger les choses à ce niveau là.


  4. OPCoach
    8 février 2012

    Quels sont les fichiers qui peuvent poser problème avec maven ? En ne les stockant pas, les développeurs vont avoir des configurations différentes pour leurs projets…


  5. Florin
    7 février 2012

    Globalement je suis d’accord. Le point 6 sur le “Commit des fichiers de gestion d’Eclipse” me pose un souci pour les projet gérés avec Maven. J’ajouterais également l’option qui “formatte” automatiquement le code lors de la sauvegarde. Et aussi un checkstyle. My 2cents…

Laisser un commentaire