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.
- 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.
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.
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
Merci pour cet article !
Dans le cadre de notre socle technique Java Open Source, nous avons aussi eu à faire un Eclipse packagé pour industrialiser notre développement…
Le tout est open source : http://www.scub-foundation.org/
Une grande partie de tout ça est fourni par Maven. Cela permet aux développeurs de garder leurs habitudes dans leur IDE…
Merci Nicolas de partager tes trucs et astuces ;)
Je confirme, cette opération est obligatoire qd l’équipe est composée de plus d’un membre et/ou est localisée sur plusieurs sites (mon cas).
J’ai paramétré cela de façon légèrement différente, en utilisant la commande import/export des préférences d’eclipse.
Sauf erreur, elle remplit la grande majeure des actions que tu décris (pour le repository svn, je n’en sais rien ^^).
Maven permet de configurer pas mal de ce que l’article détail (PMD, Checkstyle, encoding, etc.).
Pour les pb de chemins de fichiers différents, il suffit de lancer eclipse avec un script qui place un lien symbolique au même endroit pour tout le monde.
Dans le même ordre d’idée, il y a aussi le plugin workspacemechanic (http://code.google.com/a/eclipselabs.org/p/workspacemechanic/) qui peut être intéressant…