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


87

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?


Réponses:


65

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 :

Le chemin de construction prend 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:

variable de chemin avec chemin relatif
(depuis 3.6M5)


2
Wow, je ne savais pas qu'ils avaient ajouté ceci ... Cela nous aurait sauvé du chagrin
Uri

Il semble que les images associées à cette réponse soient hors ligne.
vkraemer

1
@vkraemer: vrai. J'ai maintenant restauré ces deux images, la première provenant de archive.eclipse.org/eclipse/downloads/drops/R-3.5-200906111540/... et la seconde de download.itemis.com/mirror/eclipse/R-3.6 -201006080911 ./ ....
VonC

17

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.


31
Je ne peux pas être d'accord. D'après mon expérience, il est bon d'enregistrer ces fichiers pour rendre le paiement aussi facile que possible. Quelqu'un pourrait les changer d'une manière étrange? Quelqu'un pourrait changer votre code d'une manière étrange ...
Arne Deutsch

Arne, tu devrais en faire une réponse, pas un commentaire.
amarillion

5
Les fichiers de projet pour tout IDE ne font en fait partie d'aucun projet - si vous voulez les distribuer - allez ahed - joignez-les à l'article que j'ai mentionné. Généralement, tout le monde dans une équipe peut modifier les fichiers du référentiel, mais tout le monde ne peut pas attacher de nouveaux fichiers aux nœuds de documentation importants, etc. Il est très facile pour quelqu'un d'oublier d'ignorer le chemin de classe et les fichiers de projet et de les valider quand il ne le devrait pas. Même si vous les gardez dans la subversion - vous devriez certainement les garder quelque part sur le côté ...
Bozhidar Batsov

8
-1, je ne pourrais pas être plus en désaccord. Les paramètres de projet sont une partie cruciale du travail quotidien avec un projet. Les inconvénients de la vérification accidentelle de mauvais paramètres sont beaucoup moins importants que les avantages de tenir automatiquement tout le monde à jour. Après tout, vous pouvez toujours facilement revenir aux versions précédentes.
Michael Borgwardt

7
Chacun a droit à une opinion. En fait, je ne créerais jamais un projet reposant sur le système de projet d'Eclipse (ou de tout autre IDE) en premier lieu ... Maven est l'outil ultime de compréhension de projet et rend obsolètes les configurations spécifiques à l'IDE. Btw le temps de remarquer que quelque chose ne va pas avec les paramètres actuels et de revenir à la révision précédente est peu susceptible de différer du moment pour ajuster les nouveaux paramètres vous-même. Au moins dans mon entreprise, tout le monde dans l'équipe est averti par e-mail si une intervention de l'utilisateur est nécessaire après des changements plus importants.
Bozhidar Batsov

10

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


m2e fait la plupart mais pas tout pour vous
Junchen Liu

6

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.


Est-ce le cas même lors de l'utilisation d'environnements d'exécution pour JRE / JVM?
Mr_and_Mrs_D

5

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.


5

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.


2

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.