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

Question

Je suis en cours d'exécution de l'open source de java projet qui se compose de plusieurs modules dans un arbre de dépendances. Tous ces modules sont des sous-répertoires dans un dépôt subversion. Pour les nouveaux arrivants à notre projet, c'est beaucoup de travail pour définir tout ce que manuellement dans eclipse.

Pas tous nos développeurs utilisent eclipse. Néanmoins, nous envisageons de simplement vérifier dans le .et de classpath .les fichiers de projet pour aider les nouveaux arrivants à obtenir commencé. Est-ce une bonne idée? Ou serait-ce conduire à des conflits constants dans ces fichiers? Est-il une autre façon de faire le projet facile à mettre en place sur eclipse?

Answer 1

Définitivement oui, comme je l'ai dit dans "voulez-vous garder vos fichiers de projet sous contrôle de version?"

"Le charger, jeu, allez."

Mais... ce qui est vrai seulement pour les dernières Eclipse3.5 paramètres, où l'accumulation des chemins relatifs dans les chemins:

---

Et Eclipse3.6 serait mieux, car il prend en charge les chemins relatifs pour les variables de chemin d'accès en Linked Resources:

(depuis le 3.6M5)

Answer 2

Absolument non, c’est une idée généralement terrible 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 LISEZMOI dans Subversion contient les mêmes informations.

Answer 3

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

Answer 4

Je voudrais vérifier ces fichiers pour faire le départ pour les nouveaux utilisateurs aussi facile que possible. Au mieux, l'utilisateur doit consulter le projet et devrait être en mesure de l'exécuter sans connaissances supplémentaires. Pour ce fichiers les règles sont les mêmes que pour les autres fichiers dans le projet: les manipuler avec soin. Vous ne devriez pas vous les chemins absolus dans le code source, neigther vous devez dans les fichiers de configuration.

Si les fichiers sont archivés de façon que le projet s'exécute à partir de zéro, il ne devrait pas être beaucoup de forces de les changer.

Answer 5

Je vous recommanderais de vérifier les fichiers dans subversion SI 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 similaires, un fichier README serait un meilleur choix.