.classpath und .project - in die Versionskontrolle einchecken oder nicht?

Question

Ich führe ein Open-Source-Java-Projekt, das aus mehreren Modulen in einer Struktur von Abhängigkeiten besteht. All diese Module sind Unterverzeichnisse in einem Subversion-Repository. Für Neueinsteiger in unser Projekt ist es eine Menge Arbeit, all das manuell in Eclipse einzurichten.

Nicht alle unsere Entwickler verwenden Eclipse. Nichtsdestotrotz denken wir darüber nach, einfach die .classpath- und .project-Dateien einzuchecken, um Neueinsteigern den Einstieg zu erleichtern. Ist das eine gute Idee? Oder würde das zu ständigen Konflikten in diesen Dateien führen? Gibt es eine alternative Möglichkeit, das Projekt auf Eclipse einzurichten?

Answer 1

Definitiv ja, wie gesagt in „Do you keep your project files under version control?“

"Lade es auf, richte es ein, geh."

Aber ... das gilt eigentlich nur für den letzten Eclipse3.5 Einstellungen, wo Pfade Unterstützung relative Pfade bauen:

---

Und Eclipse3.6 besser wäre , da relative Pfade für Pfadvariablen unterstützt in Linked Resources:

(seit 3.6M5)

Answer 2

Definitiv nein - es ist generell eine schreckliche Idee, Projektdateien über Subversion zu verteilen. Zumal jemand sie auf eine seltsame Art modifizieren könnte. Eine gute Seite in der Projektdokumentation ist eine viel bessere Idee. Unser Projekt hat auch viele Module und ein komplexes Setup. Wir haben eine Confluence-Seite eingerichtet, die beschreibt, wie Sie mit dem Projekt auf jeder populeren IDE beginnen - IntelliJ, Eclipse, NetBeans. Eine README-Datei in Subversion enthält die gleichen Informationen.

Answer 3

Ich würde diese Dateien überprüfen, um den Start für neue Benutzer so einfach wie möglich zu machen. Im besten Fall sollte der Benutzer das Projekt auschecken und es ohne zusätzliche Kenntnisse ausführen können. Für diese Dateien gelten dieselben Regeln wie für andere Dateien im Projekt: Behandeln Sie sie mit Vorsicht. Sie sollten keine absoluten Pfade im Quellcode platzieren, unabhängig davon, was Sie in den Konfigurationsdateien tun sollten.

Wenn die Dateien so eingecheckt werden, dass das Projekt von Grund auf neu gestartet wird, sollte es nicht viel Kraft geben, sie zu ändern.

Answer 4

Ich würde empfehlen, dass Sie die Dateien in Subversion überprüfen, wenn sie keine absoluten Pfade und andere Daten enthalten, die sie direkt an die Umgebung eines einzelnen Entwicklers binden würden.

Wenn die Dateien absolute Pfade und ähnliches enthalten, wäre eine README die bessere Wahl.

Answer 5

Ja, überprüfen Sie sie definitiv, aber stellen Sie sicher, dass Sie alle Pfadabhängigkeiten dokumentieren und absolute Pfade möglichst vermeiden.

Wenn Sie sie nicht einchecken, muss jeder, der das Projekt überprüft, alle diese Einstellungen neu erstellen, was ärgerlich und möglicherweise fehleranfällig ist.

Einige komplex Setups besser durch einen Skript behandelt werden können, diese Dateien zu erzeugen, aber in der Regel ist es besser, nur um sie in zu überprüfen.

Answer 6

Ich stimme nicht, aber das ist, weil ich in der Regel diese Dateien von Maven

Answer 7

Nach meiner Erfahrung erzeugen würde, die begrenzten Fälle außer die rein lokale Einstellungen beteiligt sind, soll alles in der Quellcodeverwaltung sein. Das Gesetz der Quellenkontrolle besagt, dass alles, was eingedrungen ist, von denjenigen erwartet werden sollte, die sich zurückziehen. Leider verursacht verdunkeln oft Dinge wie diese in .classpath sein:

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

So auf meinem Mac das funktioniert, und vielleicht jemand auf einem Mac hat die gleiche JRE, aber das wird für alle anderen nicht.

Auch gibt es keinen einfachen Weg um diese. Eclipse wird das immer hinzufügen. Ich möchte die .classpath-Datei dort haben, weil es einige JARs von Drittanbietern in unserem Lib-Ordner gibt, wo wir uns um die Versionierung kümmern, also lassen wir sie dort, damit neue Entwickler sie nicht bekommen müssen . Wir ziehen auf ein verwaltetes System um, haben jedoch + verwaltete Abhängigkeiten verwaltet. Dies bedeutet, dass alle Entwickler nur sicherstellen müssen, dass sich zwei Verzeichnisse in ihren .classpath s befinden. Aber es ist besser, als wenn Sie jedes Mal, wenn Sie ziehen, Ihren JRE reparieren müssen und jedes Mal, wenn Sie sich verpflichten, eine Änderung in Ihrem .classpath vornehmen.

Eclipse tut ein paar andere schöne Dinge für Sie. Die .project-Datei ist normalerweise in allen Instanzen gleich. Das Beste an der Quellcodeverwaltung für Eclipse sind jedoch die Einstellungen für die Ausführungskonfiguration. Speichern Sie auf der Registerkarte "Allgemein" im Dialogfeld "Konfigurationen ausführen" die Konfigurationen so, dass sie für Ihre Kollegen unter den Favoritenlisten für Debug und Ausführen angezeigt werden. Für mich gehen eine Reihe von .launch Dateien in das Verzeichnis .settings, so dass wir alle sie verwenden können.

Also sage ich: .settings Verzeichnis geht in die Quellcodeverwaltung für den Start configs (außer * .prefs)

.classpath bleibt aus

.project geht in