Un workspace Eclipse standardisé

Uniformiser vos environnements de développement - Gagner en productivité

Marre des merges galères pour cause de formateurs différents ?

• Marre qu'un membre de l'équipe commit en UTF-8, l'autre en ISO-8859-1 ?
• Marre de reconfigurer la JDK, Checkstyle, PMD, le repo SVN, le proxy de la boite, et des millions de paramètres à chaque création d'un nouveau workspace ?

Ce tip & trick est pour vous !

Vous savez qu'Eclipse stocke toute cette configuration dans le répertoire ".metadata" du workspace. Je vous propose donc de créer un Generic-Metadata.zip pour tous les membres de votre projet.

Le but étant que chacun puisse créer son workspace avec une configuration identique et ce en deux clics ! Libre à lui, ensuite, de remettre rose sa couleur de police...

Comment créer ce Zip ?

• Créez un nouveau workspace Eclipse.
• Faites tous les réglages que vous souhaitez. Attention, ils doivent être indépendants de la machine. En effet, si vous faites un réglage qui pointe vers " C:\Users\Nicolas" cela risque de mettre à mal la généricité... C'est la seule contrainte.- Fermez votre Eclipse.
• Il ne vous reste plus qu'à zipper le répertoire .metadata présent dans le workspace (il ne doit, d'ailleurs, y avoir que ce répertoire) et placer le fichier Generic-Metadata.zip sur un répertoire partagé par tout le projet.

Comment utiliser ce Zip ?

• Créez le répertoire de votre futur workspace à la main (il ne doit pas y avoir de .metadata).
• Dezippez le zip dans ce répertoire (le répertoire .metadata se trouve maintenant à la base du workspace).
• Vous n'avez plus qu'à ouvrir votre workspace via Eclipse.

Que peut-on y mettre ?

Voici ce que je positionne en général dans ce Zip :

• le formateur officiel de l'entreprise
• les fichiers de configuration Checkstyle/PMD de l'entreprise
• l'encodage
• les actions automatiquement lancées à chaque sauvegarde de fichier (organisation des imports, formatage, etc.)
• le dépôt SVN du projet
• la JDK (tous les postes de développement doivent donc l'avoir installée de façon homogène)
• le proxy de l'entreprise

Conclusion

Rien d'exceptionnel dans cette pratique, mais dans une perspective d'amélioration de la productivité, je trouve que son gain est colossal pour un coût dérisoire.

Dangers & Conseils

-pourquoi un Zip ?

Premièrement ce répertoire .metadata est constitué de nombreux fichiers. En cas de transfert, il est plus efficace de copier un seul fichier.

Deuxièmement, sous Windows, il n'est pas possible de créer simplement un répertoire dont le nom commence par un point. En dézippant le Generic-Metadata.zip, plus de souci !

Il serait aussi envisageable d'utiliser un SCM pour ce répertoire .metadata. Cela aurait en plus l'avantage de pouvoir versionner.

-un Eclipse associé

Il est possible et même conseillé d'avoir à coté de ce Zip un Eclipse préconfiguré possédant tous les plugins utilisés sur le projet.

- Maintien non optimal...

Comme tout standard, cette pratique doit être vivante. Tout le monde peut/doit faire évoluer ce Zip.

Si une nouvelle configuration émerge (ex. pour un nouveau plugin utilisé) il faut tout de suite penser à mettre à jour ce Generic-Metadata.zip. Tous les nouveaux workspaces créés prendront en compte cette nouvelle configuration.

Mais attention.

Seulement les nouveaux workspaces créés auront ces dernières configurations.

De plus un workspace dans lequel on a déjà importé des projets ne peut plus servir à générer un Generic-Metadata.zip.

Prenons un exemple :

• le techlead a créé et partagé un GeneriqueMetadata-V0.zip
• René s'en est servi pour créer son workspace et il y a importé ses projets
• il a ensuite modifié sa configuration (ex. pour que la javadoc soit générée automatiquement, une meilleure disposition des vues, etc.)
• René ne peut plus générer de GeneriqueMetadata.zip à partir de ce workspace car il a été "pollué" par des informations spécifiques au projet, à sa machine, etc.

Pour partager sa configuration René doit :

• utiliser dans un workspace vide le GeneriqueMetadata-V0.zip (cf. Comment utiliser ce Zip ?)
• faire ses modifications de configuration
• rezipper en un GeneriqueMetadata-V1.zip et partager cette nouvelle version

Si maintenant un autre membre du projet souhaite se mettre à jour et veut utiliser le GeneriqueMetadata-V1.zip, c'est lui qui va perdre sa configuration spécifique.

Amélioration ?

Un répertoire .metadata sur le SVN avec seulement la configuration non spécifique de commitée. Il me semble que cela deviendrait trop couteux. En effet, il faudrait alors analyser le contenu de ce répertoire. Si vous voulez tenter... Bonne chance et merci de partager vos retours !

Pas convaincu ?

Je vous donne une piste à creuser si vous avez la chance d'être sous Helios. Le récent Maven Studio de Sonatype pour Eclipse Helios :

http://www.sonatype.com/books/m2eclipse-book/reference/mse-quickstart.html