Quels fichiers Eclipse sont sous contrôle de version?
Quels fichiers Eclipse convient-il de placer sous contrôle de source, en dehors des sources évidemment?
Dans mon projet, en particulier, je m'interroge sur:
.metadata/*
rép_projet/.project
rép_projet/.classpath
projet-dir/.settings/*
Si cela dépend de l'un de ceux-ci, veuillez expliquer vos directives.
Les métadonnées ne doivent pas être gérées dans le contrôle de source. Ils contiennent principalement des données pertinentes pour votre espace de travail.
La seule exception est le .launch Fichiers XML (définition du lanceur).
Ils se trouvent dans
[Eclipse-workspace]\.metadata\.plugins\org.Eclipse.debug.core\.launches
Et elles doivent être copiées dans votre répertoire de projet: Lorsque votre projet est actualisé, ces configurations seront affichées dans la boîte de dialogue "Exécuter la configuration".
De cette façon, ces fichiers de paramètres de lancement peuvent également être gérés dans le SCM.
(Attention: Ne décochez l'option "Supprimer les configurations lorsque la ressource associée est supprimée" dans le Run/Launching/ Lancer la configuration panneau de préférences: Il est courant de supprimer un projet à l'aide d'un logiciel afin de le réimporter - pour forcer la réinitialisation des métadonnées Eclipse. Mais cette option, si cochée, supprimera vos paramètres de lancement détaillés!)
project-dir/.project
project-dir/.classpath
project-dir/.settings/*
devrait être dans votre SCM (surtout .project et .classpath selon le documentation Eclipse ).
L'objectif est que tout le monde puisse extraire/mettre à jour son espace de travail SCM et importer le projet Eclipse dans l'espace de travail Eclipse.
Pour cela, vous voulez utiliser uniquement les chemins relatifs dans votre .classpath, en utilisant ressources liées.
Note: mieux vaut project-dir fait référence à un répertoire de projet "externe" et non à un répertoire créé dans l'espace de travail Eclipse. De cette façon, les deux notions (espace de travail Eclipse et espace de travail SCM) sont clairement séparées.
Comme ipsquiggle est mentionné dans le commentaire, et comme je l’ai déjà mentionné dans une réponse ancienne , vous pouvez enregistrer la configuration de lancement en tant que partagée. fichier directement dans le répertoire de votre projet. Toute la configuration de lancement peut alors être versionnée comme les autres fichiers du projet.
(Extrait de l'article de blog Astuce: Création et partage de configurations de lancement de KD)
Je travaille actuellement sur un projet dans lequel nous contrôlons le code source des fichiers .project et .cproject. L'idée était que les paramètres liés aux chemins de bibliothèque et aux directives de liaison se propageaient dans l'équipe.
En pratique, cela n'a pas très bien fonctionné, les fusions reviennent presque toujours dans un état conflictuel qui doit être résolu en dehors d'Eclipse, puis le projet est fermé et rouvert pour que les modifications prennent effet.
Je ne recommanderais pas de les garder sous contrôle de code source.
Cela ne vaut rien que CDT les fichiers de configuration ne sont pas adaptés au contrôle de source. Un bogue a été enregistré pour les fichiers .cproject qui changent très fréquemment et qui provoquent des conflits, voir Le partage de fichiers cdt-project dans le référentiel provoque toujours des conflits.
Certains projets, comme ceux utilisant Maven, aiment générer les fichiers .project basés sur des POM.
Cela dit, à part cela - .metadata NE DOIT PAS être sous contrôle de source. Votre projet devra déterminer si le paramètre rép_projet/.settings est correct, en fonction de la manière dont vous envisagez de gérer les normes, etc. Si vous pouvez vraiment faire confiance à vos développeurs pour configurer leur environnement sur la base de la norme et que vous ne devez rien personnaliser de particulier pour un projet, vous n'avez pas besoin de les intégrer. Moi, je vous recommande de configurer chaque projet spécifiquement . Cela permet aux développeurs de travailler sur des projets de plusieurs projets dans le même espace de travail sans avoir à changer les paramètres par défaut. Cela rend les paramètres très explicites, en remplaçant les paramètres par défaut correspondant aux normes du projet.
La seule difficulté est de s’assurer qu’ils restent tous synchronisés. Mais dans la plupart des cas, vous pouvez copier les fichiers .settings de projet en projet. S'il y en a que vous ne voulez pas spécifiquement dans le contrôle de code source, effectuez l'équivalent de définir svn: ignore pour eux, si votre SCM le prend en charge.
Le fichier .classpath est définitivement un bon candidat pour vérifier dans scm car le configurer à la main peut être un travail laborieux et sera difficile pour les nouveaux développeurs entrant dans le projet. Il est vrai qu'il peut être généré à partir d'autres sources. Dans ce cas, vous devriez vérifier l'autre source.
Quant aux réglages, cela dépend des réglages. Il s'agit d'une zone grise, mais certains paramètres sont presque obligatoires et il est pratique de pouvoir extraire un projet, de l'importer dans Eclipse et de tout configurer et de commencer.
Lors de notre projet, nous conservons donc une copie du dossier .settings appelé CVS.settings et nous avons une tâche de copie pour la copier dans .settings. Lorsque vous recevez le projet de CVS, vous appelez la tâche ant 'eclipsify' pour copier les paramètres par défaut dans le nouveau dossier .settings. Lorsque vous configurez les paramètres requis par tous ceux qui développent sur le projet, vous les fusionnez dans le dossier CVS.settings et les transmettez à CVS. Ainsi, l'enregistrement des paramètres dans SCM devient un processus conscient. Cela oblige les développeurs à fusionner ces paramètres dans leurs dossiers .settings de temps en temps lorsque de gros changements sont enregistrés. Mais c'est un système simple qui fonctionne étonnamment bien.
Je dirais aucun d'entre eux. Ils contiennent probablement des informations qui ne concernent que votre poste de travail (je pense aux chemins des bibliothèques et autres). De plus, que se passe-t-il si quelqu'un dans votre équipe n'utilise pas Eclipse?
Considérer:
.classpath
.project
.launch
Ceux-ci DEVRAIENT être dans le contrôle de version aussi longtemps que vous vous en tenez à utiliser des chemins relatifs au projet. Cela permet aux autres développeurs de consulter le projet et de commencer à travailler immédiatement sans avoir à passer par toutes les difficultés d'installation que les autres développeurs ont également rencontrées.
Vous serez peut-être tenté d'inclure .metadata dans le contrôle de version afin que les développeurs Eclipse puissent extraire un espace de travail complet et le préconfigurer avec tous les projets appropriés. Toutefois, il contient de nombreuses informations spécifiques à l'utilisateur changer, donc je conseillerais de ne pas inclure. Metadata. Il est facile de créer un espace de travail local simplement en important tous les projets Eclipse existants.
J'ai passé trop d'heures à configurer les paramètres de l'espace de travail Eclipse pour les nouveaux collègues (et moi-même). Ce que j’ai fini par faire, c’est finalement de copier mon propre fichier .metadata sur la nouvelle machine de développement.
Si vous travaillez dans une équipe, alors je pense que les personnes suivantes sont de très bons candidats pour garder le contrôle de version:
- JRE installés et leurs noms
- Environnements d'exécution serveur
- Modèles d'éditeur Java
- Raccourcis clavier de contrôle de version
- Paramètres de plug-in qui ne fournissent pas de paramètres spécifiques au projet
- Paramètres Maven
- Perspectives préconfigurées
- ...