.classpath et .project - archiver ou non le contrôle de version?

J'exécute un projet java open source qui se compose de plusieurs modules dans une arborescence de dépendances. Tous ces modules sont des sous-répertoires dans un référentiel subversion. Pour les nouveaux arrivants dans notre projet, c'est beaucoup de travail de configurer tout cela manuellement en éclipse.

Tous nos développeurs n'utilisent pas eclipse. Néanmoins, nous envisageons de simplement archiver les fichiers .classpath et .project pour aider les nouveaux arrivants à démarrer. Est-ce une bonne idée? Ou cela conduirait-il à des conflits constants dans ces fichiers? Existe-t-il un autre moyen de rendre le projet facile à mettre en place sur eclipse?

Certainement oui, comme je l'ai dit dans " Gardez-vous vos fichiers de projet sous contrôle de version? "

"Chargez-le, configurez-le, allez."

Mais ... cela n'est en fait vrai que pour les paramètres récents d'Eclipse3.5, où les chemins de construction prennent en charge les chemins relatifs :

Et Eclipse3.6 serait mieux, car il prend en charge les chemins relatifs pour les variables de chemin dans Linked Resources:

(depuis 3.6M5)

Certainement pas - c'est généralement une mauvaise idée de distribuer des fichiers de projet via subversion. Surtout que quelqu'un pourrait les modifier d'une manière étrange. Une bonne page dans la documentation du projet est une bien meilleure idée. Notre projet comporte également de nombreux modules et une configuration complexe. Nous avons mis en place une page de confluence décrivant comment démarrer avec le projet sur chaque IDE populer - IntelliJ, Eclipse, NetBeans. Un fichier README dans Subversion contient les mêmes informations.

Je vote non, mais c'est parce que je générerais généralement ces fichiers à partir de maven

D'après mon expérience, à l'exclusion des cas limités où des paramètres purement locaux sont impliqués, tout devrait être sous contrôle de code source. La loi du contrôle à la source est que tout ce qui est poussé devrait fonctionner par ceux qui se retirent. Malheureusement, l'éclipse provoque souvent des choses comme celle-ci .classpath:

    <classpathentry kind="con" 
      path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.launching.macosx.MacOSXType/Java SE 7"/>

Donc, sur mon Mac, cela fonctionne, et peut-être que quelqu'un sur un Mac a le même JRE, mais cela ne fonctionnera pour personne d'autre.

De plus, il n'y a pas de moyen facile de contourner cela. Eclipse ajoutera toujours cela. Je VEUX avoir le fichier .classpath là-dedans, car il y a des JAR tiers dans notre dossier lib où nous nous soucions du contrôle de version, donc nous les laissons là-dedans pour que les nouveaux développeurs n'aient pas à les obtenir . Nous passons à un système géré, mais les dépendances managées + non gérées sont toujours enregistrées. Cela signifie que tous les développeurs doivent simplement s'assurer que deux répertoires sont dans leurs .classpaths. Mais c'est mieux que d'avoir à réparer votre JRE chaque fois que vous tirez et que vous modifiez votre .classpath à chaque fois que vous vous engagez.

Eclipse fait cependant d'autres belles choses pour vous. Le fichier .project sera généralement le même dans toutes les instances, alors incluez-le. Mais la meilleure chose à propos du contrôle de source pour eclipse est les paramètres d'exécution des configurations. Sous l'onglet "Commun" de la boîte de dialogue Exécuter les configurations, enregistrez les configurations afin qu'elles apparaissent pour vos collègues sous les listes de favoris pour le débogage et l'exécution. Pour moi, un tas de .launchfichiers vont dans le .settingsrépertoire, donc nous pouvons tous les utiliser.

Donc je dis: le .settingsrépertoire entre dans le contrôle de code source pour les configurations de lancement (sauf * .prefs)

.classpath reste dehors

.project va dans.

Je vérifierais ces fichiers pour faciliter au maximum le démarrage des nouveaux utilisateurs. Au mieux, l'utilisateur doit vérifier le projet et doit pouvoir l'exécuter sans connaissances supplémentaires. Pour ces fichiers, les règles sont les mêmes que pour les autres fichiers du projet: manipulez-les avec précaution. Vous ne devez pas placer de chemins absolus dans le code source, pas plus que dans les fichiers de configuration.

Si les fichiers sont archivés de manière à ce que le projet s'exécute à partir de zéro, il ne devrait pas y avoir beaucoup de force pour les modifier.

Je vous recommande de vérifier les fichiers dans subversion S'ils ne contiennent pas de chemins absolus et d'autres données qui les lieraient directement à l'environnement d'un seul développeur.

Si les fichiers contiennent des chemins absolus et autres, un README serait un meilleur choix.

Oui, archivez-les définitivement, mais assurez-vous de documenter toutes les dépendances de chemin et évitez si possible les chemins absolus.

Si vous ne les archivez pas, toute personne qui extrait le projet devra recréer tous ces paramètres, ce qui est ennuyeux et potentiellement sujet aux erreurs.

Certaines configurations complexes peuvent être mieux gérées par un script pour générer ces fichiers, mais il est généralement préférable de simplement les archiver.