Dois-je conserver mes fichiers de projet sous contrôle de version? [fermé]

Question

Dois-je conserver des fichiers de projet tels que Eclipse .project, .classpath, .settings, sous contrôle de version (par exemple, Subversion, GitHub, CVS, Mercurial, etc.)?

Answer 1

Vous souhaitez conserver dans le contrôle de version tous les fichiers de paramètres portables ,
signification:
Tout fichier ne contenant aucun chemin absolu.
Cela comprend:

• .project,
• .classpath ( si aucun chemin absolu n'est utilisé , ce qui est possible avec l'utilisation de variables IDE ou de variables d'environnement utilisateur)
• Paramètres de l'EDI (c'est pourquoi je ne suis pas du tout d'accord avec la réponse "acceptée"). Ces paramètres incluent souvent des règles d'analyse de code statique qu'il est primordial d'appliquer de manière cohérente à tout utilisateur chargeant ce projet dans son espace de travail.
• Les recommandations relatives aux paramètres spécifiques à l'EDI doivent être écrites dans un gros fichier README (et également bien sûr).

Règle de base pour moi:
Vous devez être en mesure de charger un projet dans un espace de travail et de disposer de tout ce dont vous avez besoin pour le configurer correctement dans votre IDE et démarrer en quelques minutes.
Aucune documentation supplémentaire, pages wiki à lire ou non.
Chargez-le, installez-le, partez.

Answer 2

Fichiers .project et .classpath oui. Cependant, nous ne conservons pas nos paramètres IDE dans le contrôle de version. Certains plugins ne résistent pas bien aux paramètres persistants et nous avons constaté que certains paramètres n'étaient pas très portables d'une machine de développement à la suivante. Nous avons donc à la place une page Wiki qui décrit les étapes nécessaires à un développeur pour configurer son environnement de développement.

Answer 3

Ce sont ce que je considère être des fichiers générés et, en tant que tels, je ne les place jamais sous contrôle de version. Ils peuvent être différents d’une machine à l’autre et d’un développeur à l’autre, par exemple lorsque différents plug-ins Eclipse sont installés.

À la place, j'utilise un outil de construction (Maven) capable de générer les versions initiales de ces fichiers lorsque vous effectuez une nouvelle extraction.

Answer 4

Je suis déchiré entre deux options ici.

D'une part, je pense que tout le monde devrait être libre d'utiliser l'ensemble des outils de développement avec lesquels il est le plus productif, à condition que tous les artefacts source soient stockés dans le contrôle de version, et que le script de construction (par exemple, ANT ou Maven) garantisse conformité aux normes en spécifiant exactement le JDK à utiliser, les versions des bibliothèques tierces sur lesquelles compter, la vérification de style (par exemple, le style de contrôle) et le lancement de tests unitaires, etc.

D'autre part, je pense que beaucoup de gens utilisent les mêmes outils (par exemple, Eclipse) et qu'il est souvent préférable de normaliser certaines choses au moment de la conception plutôt que de les construire - par exemple, Checkstyle est bien plus utile en tant qu'Eclipse. plug-in plutôt qu’en tant que tâche ANT ou Maven - qu’il est préférable de standardiser l’ensemble des outils de développement et un ensemble commun de plugins.

J'ai travaillé sur un projet où tout le monde utilisait exactement le même JDK, la même version de Maven, la même version d'Eclipse, le même ensemble de plug-ins Eclipse et les mêmes fichiers de configuration (par exemple, les profils Checkstyle, les règles de formatage de code, etc.). Tous ces éléments étaient conservés dans le contrôle de code source: .project, .classpath et tout ce qui se trouvait dans le dossier .settings. Cela simplifiait vraiment la vie durant les phases initiales du projet, lorsque les utilisateurs peaufinaient continuellement les dépendances ou le processus de construction. Cela a également beaucoup aidé lors de l’ajout de nouveaux partants au projet.

Dans l’ensemble, je pense que s’il n’ya pas trop de chances d’une guerre religieuse, vous devriez normaliser l’ensemble de base des outils de développement et des plug-ins et garantir la conformité de la version dans vos scripts de construction (par exemple en spécifiant explicitement la version Java). ). Je ne pense pas qu’il soit très avantageux de stocker le JDK et l’installation d’Eclipse dans le contrôle de source. Tout ce qui ne constitue pas un artefact dérivé - y compris vos fichiers de projet, vos préférences de configuration et de plug-in (notamment les règles de formatage et de style) - doit être placé dans le contrôle de source.

P.S. Si vous utilisez Maven, il existe un argument pour affirmer que les fichiers .project et .classpath sont des artefacts dérivés. Cela n’est vrai que si vous les générez à chaque fois que vous créez, et si vous n’avez jamais eu à les ajuster manuellement (ou les avez modifiées par inadvertance en modifiant certaines préférences) après les avoir générées à partir du POM

Answer 5

Non, car je ne contrôle que les fichiers de contrôle de version nécessaires à la création du logiciel. De plus, chaque développeur peut avoir ses propres paramètres spécifiques au projet.

Answer 6

Non, je suis un gros utilisateur de Maven et j'utilise le plug-in Q pour Eclipse qui crée et met à jour les fichiers .project et .classpath. Pour d’autres choses telles que les paramètres de plugins, j’ai en général gardé un fichier README ou Wiki à ce sujet.

De plus, ceux avec qui j'ai travaillé préfèrent d'autres IDE utilisent simplement les plug-ins Maven pour générer les fichiers nécessaires à la satisfaction de leur IDE (et d'eux-mêmes).

Answer 7

Ceci n’est que l’opinion, je suppose - mais les meilleures pratiques observées au fil des ans indiquent que les fichiers spécifiques à un IDE donné ne doivent pas être stockés dans le contrôle de source, à moins que l’ensemble de votre entreprise soit normalisée sur un seul IDE et que vous n’ayez jamais l’intention de le faire. commutation.

Quoi qu'il en soit, vous ne voulez certainement pas que les paramètres utilisateur soient stockés - et .project peut contenir des paramètres vraiment spécifiques au développeur.

Je recommande d'utiliser quelque chose comme Maven ou Ant en tant que système de construction normalisé. Tout développeur peut obtenir un chemin de classe configuré dans son IDE en quelques secondes.

Answer 8

Oui, sauf pour le dossier .settings. La validation des autres fichiers fonctionne bien pour nous. Il existe une question similaire ici

. >

Answer 9

Bien que je sois généralement d’accord sur les fichiers " ne pas générer de version " approche, nous avons des problèmes avec elle et devons revenir en arrière.

  

Remarque: je suis également intéressé par La réponse de VonC , en particulier à propos de l'option "Obtenir Eclipse en quelques minutes". point. Mais ce n'est pas décisif pour nous.

Notre contexte est Eclipse + Maven, utilisant le plug-in m2eclipse. Nous avons un environnement de développement commun, avec des répertoires communs autant que possible. Mais il arrive parfois que quelqu'un essaie un plug-in, modifie de petites choses dans la configuration ou importe un deuxième espace de travail pour une autre branche ...

Notre problème est que la génération du fichier .project est effectuée lors de l'importation d'un projet dans Eclipse, mais n'est pas mise à jour ultérieurement dans tous les cas . C'est triste et probablement pas permanent car le plug-in m2eclipse va s'améliorer, mais c'est vrai pour le moment. Nous finissons donc par avoir différentes configurations. Ce que nous avions aujourd’hui, c’est que: plusieurs natures ont été ajoutées à de nombreux projets sur certaines machines, qui se sont ensuite comportées de manière très différente : - (

La seule solution que nous voyons consiste à versionner le fichier .project (pour éviter les risques, nous ferons de même pour .classpath et .settings). Ainsi, lorsqu'un développeur modifie son pom, les fichiers locaux sont mis à jour à l'aide de m2eclipse, ils sont tous validés ensemble et les autres développeurs voient toutes les modifications.

  

Remarque: dans notre cas, nous utilisons des noms de fichiers relatifs. Nous n'avons donc aucun problème à partager ces fichiers.

Donc, pour répondre à votre question, je réponds oui à ces fichiers.

J'ai aussi aimé:

• Rich Seller réponse

Answer 10

Il semble que ces fichiers de projet puissent changer au fil du temps lorsque vous travaillez sur un projet, alors oui, je les place sous contrôle de version.

Answer 11

Oui. Tout sauf la production de sortie.

Answer 12

Nous utilisons IntelliJ IDEA et conservons les versions '.sample' des fichiers de projet (.ipr) et du module (.iml) sous contrôle de version.

Un élément un peu plus important ici est le partage et la réutilisation du versioning, à mon humble avis. Mais si vous voulez partager ces configurations, quel meilleur endroit pour les mettre que le référentiel, juste à côté de tout le reste.

Quelques avantages du partage & amp; fichiers de projet versionnés:

• Vous pouvez consulter n'importe quelle balise / branche et commencer à y travailler rapidement
• Il est plus facile pour un nouveau développeur de configurer l'environnement de développement et de se mettre à niveau rapidement
• Cela adhère mieux à DRY, qui est toujours profondément satisfaisant. Auparavant, tous tous les développeurs devaient configurer ces éléments de temps en temps, effectuant essentiellement un travail répété. Bien sûr, chacun avait ses propres moyens d'éviter de se répéter, mais en regardant l'équipe dans son ensemble, il y avait beaucoup d'efforts en double.

Notez que dans IDEA, ces fichiers contiennent des configurations telles que: quelles sont les "source" " source " et " source de test " dirs; tout ce qui concerne les dépendances externes (où se trouvent les fichiers jar de la bibliothèque, ainsi que les sources associées ou javadocs); options de construction, etc. Ceci ne diffère pas d'un développeur à l'autre (je ne suis pas d'accord avec ceci assez fortement). IDEA stocke davantage de paramètres IDE personnels ailleurs, ainsi que toutes les configurations de plug-in. (Je ne connais pas très bien Eclipse; cela peut être différent ou non.)

Je suis d'accord avec cette réponse qui dit:

  

Vous devez être capable de charger un projet   dans un espace de travail et y avoir   tout ce dont vous avez besoin pour le configurer correctement   dans votre IDE et y aller   minutes.   [...]   Chargez-le, installez-le, partez.

Et nous l’avons comme ceci, grâce aux fichiers de projet versionnés.