Quels fichiers doivent être ajoutés à SVN dans un projet Java eclipse?

Question

J'ai un projet Java que j'aimerais valider dans mon dépôt SVN, créé avec eclipse.

Maintenant, quels fichiers (en dehors du code source, évidemment) sont nécessaires? Dans la racine de l'espace de travail, il y a un dossier .settings avec de nombreux fichiers et sous-dossiers, et dans le dossier du projet il y a deux fichiers - .classpath et .project, et un autre dossier .settings avec un seul fichier - org.eclipse.jdt.core .prefs.

Lequel de ces fichiers doit être validé pour SVN et qui peut être exclu en toute sécurité?

Answer 1

Ils sont tous utiles si vous voulez avoir des paramètres cohérents dans votre équipe.

.classpath et .project signifie que tout le monde peut démarrer avec un projet simplement en l'important. Toutes les modifications apportées aux bibliothèques et aux fichiers source inclus dans le projet seront récupérées par tout le monde lors de leur archivage.

Le répertoire .settings contient des options de mise en forme de code et ce que le compilateur considère comme des avertissements, des erreurs ou OK . Par souci de cohérence, j'ai aussi commencé à les vérifier (à condition que tout le monde dans votre équipe puisse accepter une norme pour le formatage, je suppose).

J'ai constaté que la plus grande limitation dans le partage des éléments à travers le contrôle de version dans Eclipse réside dans les définitions de bibliothèque. Les définitions de bibliothèque semblent être stockées uniquement par utilisateur, donc si vous référencez une "bibliothèque" dans le fichier .classpath, chaque autre utilisateur doit définir manuellement le contenu de cette bibliothèque (ou importer manuellement le fichier de définitions de bibliothèque exporté) .

---

Edit:(Répondre @ commentaire de mliebelt ci-dessous)

Vous souhaitez engager uniquement .settings fichiers si vous essayez de garder la cohérence/normalisation entre les développeurs. Si ce n'est pas un problème pour le projet, alors ne pas valider les fichiers .settings est une chose de moins à se soucier de maintenir. Les fichiers qui sont spécifiques aux plugins favoris d'un individu n'ont probablement pas besoin d'être validés non plus (bien que je ne pense pas que cela ferait mal s'ils étaient, seraient probablement ignorés?).

Les deux plus communs que j'ai trouvé la peine d'être valables sont org.eclipse.jdt.core.prefs et org.eclipse.jdt.ui.prefs, qui sont au cœur de tout projet (Java) Eclipse.

Answer 2

Vous pouvez exclure le dossier .settings, mais le fichier .project sera utile aux autres développeurs qui souhaitent reconstruire le même projet Eclipse exact. Si vous examinez le fichier, il ne doit contenir que des références relatives (si ce n'est pas le cas, vous devez le modifier comme tel).

Answer 3

Contrairement aux autres réponses, j'ai fait de meilleures expériences avec ne vérifiant pas dans le fichier .project dans les grands projets open source que je travaille avec.

Vous pouvez ne pas être d'accord avec moi, mais il y a un problème avec les fichiers .project partagés: ils contiennent des références aux natures de projet utilisées dans le projet. Les natures du projet dépendent à nouveau des plugins installés sur la machine des développeurs locaux. Exemple: Si vous utilisez Findbugs sur un projet Java, une nouvelle nature est ajoutée à votre projet Java.En vérifiant ce fichier, en le modifiant sur un autre système (sans installer de Findbugs) et en l'utilisant ensuite sur mon système, la référence Findbugs a été perdue pour moi (et donc toutes les vérifications de Findbugs ont été retirées silencieusement). Mais si vous pouvez faire en sorte que tous vos développeurs soient d'accord sur l'utilisation des mêmes outils, vous pourrez peut-être facilement contourner ce problème.