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

Ich führe ein Open-Source-Java-Projekt aus, das aus mehreren Modulen in einem Abhängigkeitsbaum besteht. Alle diese Module sind Unterverzeichnisse in einem Subversion-Repository. Für Neulinge in unserem Projekt ist es eine Menge Arbeit, all das manuell in Eclipse einzurichten.

Nicht alle unsere Entwickler verwenden Eclipse. Wir überlegen jedoch, nur die Dateien .classpath und .project einzuchecken, um Neulingen 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 einfach in Eclipse einzurichten?

Auf jeden Fall ja, wie ich in " Behalten Sie Ihre Projektdateien unter Versionskontrolle? " Sagte.

"Laden Sie es auf, richten Sie es ein, gehen Sie."

Aber ... dies gilt tatsächlich nur für aktuelle Eclipse3.5-Einstellungen, bei denen Build-Pfade relative Pfade unterstützen :

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

(seit 3.6M5)

Auf jeden Fall nein - es ist im Allgemeinen eine schreckliche Idee, Projektdateien über Subversion zu verteilen. Zumal jemand sie auf seltsame Weise modifizieren könnte. Eine gute Seite in der Projektdokumentation ist eine viel bessere Idee. Unser Projekt hat auch viele Module und einen komplexen Aufbau. Wir haben eine Konfluenzseite eingerichtet, auf der beschrieben wird, wie Sie mit dem Projekt auf jeder Populer-IDE beginnen - IntelliJ, Eclipse, NetBeans. Eine README-Datei in Subversion enthält dieselben Informationen.

Ich stimme nein, aber das liegt daran, dass ich diese Dateien im Allgemeinen aus Maven generieren würde

Nach meiner Erfahrung sollte, mit Ausnahme der begrenzten Fälle, in denen es sich um rein lokale Einstellungen handelt, alles in der Quellcodeverwaltung sein. Das Gesetz der Quellcodeverwaltung besagt, dass von allen, die sich zurückziehen, erwartet werden sollte, dass alles, was hineingedrückt wird, funktioniert. Leider führt die Sonnenfinsternis häufig dazu, dass solche Dinge auftreten .classpath:

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

Auf meinem Mac funktioniert das also, und vielleicht hat jemand auf einem Mac die gleiche JRE, aber das funktioniert bei niemand anderem.

Es gibt auch keinen einfachen Weg, dies zu umgehen. Eclipse fügt das immer hinzu. Ich möchte die .classpath-Datei dort haben, da sich in unserem lib-Ordner einige JARs von Drittanbietern befinden, in denen wir uns um die Versionierung kümmern, sodass wir sie dort belassen, damit neue Entwickler sie nicht erhalten müssen . Wir wechseln zu einem verwalteten System, haben jedoch weiterhin verwaltete + nicht verwaltete Abhängigkeiten eingecheckt. Dies bedeutet, dass alle Entwickler nur sicherstellen müssen, dass sich zwei Verzeichnisse in ihren .classpaths befinden. Aber es ist besser, als jedes Mal, wenn Sie ziehen, Ihre JRE zu reparieren und Ihren .classpath jedes Mal zu ändern, wenn Sie sich verpflichten.

Eclipse erledigt einige andere nette Dinge für Sie. Die .project-Datei ist normalerweise für alle Instanzen gleich. Schließen Sie dies ein. Das Beste an der Quellcodeverwaltung für Eclipse sind jedoch die Einstellungen für die Konfiguration ausführen. Speichern Sie auf der Registerkarte "Allgemein" im Dialogfeld "Konfigurationen ausführen" die Konfigurationen, damit sie für Ihre Kollegen in den Favoritenlisten für "Debuggen und Ausführen" angezeigt werden. Für mich .launchgehen eine Reihe von Dateien in das .settingsVerzeichnis, damit wir sie alle verwenden können.

Also sage ich: .settingsVerzeichnis geht in die Quellcodeverwaltung für Startkonfigurationen (außer * .prefs)

.classpath bleibt draußen

.project geht rein.

Ich würde diese Dateien einchecken, um den Start für neue Benutzer so einfach wie möglich zu gestalten. Bestenfalls 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: Gehen Sie vorsichtig damit um. Sie sollten keine absoluten Pfade in den Quellcode einfügen, sondern in die Konfigurationsdateien.

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

Ich würde empfehlen, dass Sie die Dateien in Subversion einchecken, 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 dergleichen enthalten, ist eine README-Datei die bessere Wahl.

Ja, auf jeden Fall einchecken, aber stellen Sie sicher, dass Sie alle Pfadabhängigkeiten dokumentieren und absolute Pfade nach Möglichkeit vermeiden.

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

Einige komplexe Setups können möglicherweise besser von einem Skript verwaltet werden, um diese Dateien zu generieren. In der Regel ist es jedoch besser, sie nur einzuchecken.