Projet Java: le fichier .classpath .project doit-il être commis dans le référentiel?

Dois-je vérifier mes fichiers .project et .classpath?

Mon ami m’a dit que je ne devais vérifier que les fichiers .java et le build.xml pour garantir la portabilité. Il a dit “.classpath vous causera beaucoup moins de portabilité sur différents environnements. .Project est entièrement votre paramètre local d’éclipse

Je suis d’accord avec lui, mais partiellement.

– Ne pas archiver le fichier .project rendra mon développement moins efficace (je ne peux pas simplement “importer” un code de projet depuis un répertoire)

– Ne pas archiver le fichier .classpath me semble correct (?) Si mon build.xml est écrit avec soin.

Quelqu’un veut partager son expérience ici?

Il n’y a rien de mal à .classpath et .classpath . Je le ferais si votre build.xml ne peut pas créer les deux fichiers pour vous. Comme vous l’avez dit, il est inconfortable de manquer ces fichiers lorsque vous essayez de créer un nouvel espace de travail Eclipse.

Avant de vous .classpath à .classpath vous .classpath vous assurer qu’il n’y a pas de chemin absolu. Convertissez-le en un relatif avec un éditeur de texte.

Edit: Ou mieux encore, utilisez les variables ecclipse classpath dans vos chemins autrement absolus, comme @ taylor-leese commenté.

Une chose contre laquelle je vous déconseille de vérifier le fichier .classpath est de vous assurer que vous ne référencez pas de fichiers en dehors de votre projet. Eclipse stocke l’emplacement de ces fichiers avec un chemin de fichier complet et vous devez vous assurer que les autres développeurs ont ces fichiers exactement au même endroit.

La question clé avec tous ces fichiers est “peuvent-ils être reproduits automatiquement?” Sinon, vérifiez-les dans le contrôle de source.

Dans ce cas, je dirais “oui”, sauf si vous utilisez maven, qui a m2eclipse et le plugin eclipse pour les générer pour vous.

Pour mes 2 centimes, je dirais que c’est une mauvaise pratique. Les projets ne doivent pas être liés à un IDE, et en particulier ne doivent pas être liés à une version spécifique d’un IDE.

La vérification dans les fichiers de configuration Eclipse pourrait bien fonctionner pour des projets plus simples et à court terme. Pour les projets plus importants qui sont développés sur plusieurs années, cela entraînera généralement plus de problèmes, car les versions IDE changent et les fichiers de configuration de projet ne le sont pas. Imaginez que vous vous connectiez dans une twig de 2 ans avec les fichiers de configuration Eclipse 2.0 dans Eclipse 4.3 avec des bibliothèques personnalisées et une intégration m2e … Pas du tout amusant …

Je ne connais pas vraiment les fichiers de préférences eclipse, mais avec IntelliJ, ces fichiers sont des agnostiques du système d’exploitation, ce qui signifie que cela ne gâchera pas votre portabilité. Sauf si vous définissez des bibliothèques avec un chemin complet vers votre système (ce serait très dangereux / stupide).

Lorsque vous partagez des préférences, vous êtes sûr que tout le monde travaillera avec les mêmes conditions sur le projet (configuration des plugins, encodage, profils [pour intelliJ]), ce qui peut vraiment être une bonne chose.

Cela ne me dérange pas quand certains fichiers Eclipse sont là, et je pense que cela ne devrait pas / ne gêne pas vraiment les autres développeurs lorsque certains fichiers cachés sont juste là.

Nous archivons .project et .classpath. Avec ProjectSet cela nous permet de vérifier les espaces de travail complexes avec un seul “Import Team ProjectSet”

Ne pas archiver le fichier .project rendra mon développement moins efficace (je ne peux pas simplement “importer” un code de projet depuis un répertoire)

pour ce problème, vous pouvez choisir de créer un nouveau projet et d’ importer une source existante .

L’un des problèmes rencontrés avec les fichiers spécifiques à IDE tels que .project est que d’autres développeurs peuvent vouloir utiliser un autre IDE pour développer le projet, afin qu’ils puissent append un autre type de fichier de projet. Cela rendra votre repo désordonné.

Je préférerais vérifier .project et .classpath.

Cela serait utile lorsque ce projet est partagé par plusieurs développeurs. Il devient facile et rapide d’installer le développement env. en l’important simplement comme projet existant sur n’importe quel système utilisant eclipse.

Seule la prudence doit être prise ici, car les chemins de classe sont relatifs au projet.

J’ai souvent un questionnement similaire, plus général. Le problème est essentiellement:

  • Quels sont les fichiers que je me suis engagé pour moi ?
  • Quels sont les fichiers que je me suis engagé pour les autres ?
  • → Comment combiner les deux objectives du “versionning”?

Je vous ai proposé d’en discuter, vous pouvez donc trouver plus de détails sur le problème, ainsi que des solutions intéressantes 🙂


Celui que j’aime le mieux est l’utilisation du git submodulegit submodule : conservez vos fichiers .project , etc. dans un repository privé. Et transformez votre production de src finale, pure et essentielle en une pépite de submodule ordonnée: un repo public.

 project/ # root module | .git # private repo | .project | .classpath | momsNumber.txt +---src/ # submodule | | .git # public repo | | main.java | +---package/ | | | Etc.java 

Voir là quand même.

Il n’y a pas de problème pour archiver les fichiers .classpath et .project dans le référentiel. Cela aidera les développeurs qui utilisent Eclipse à aller plus vite.

Avertissement : Assurez-vous que votre fichier .classpath ne fait référence qu’à des artefacts qui ont été archivés dans le référentiel avec le projet ou peuvent être obtenus automatiquement (tels que des artefacts Maven).