Ist die Datei .settings/org.eclipse.jdt.core.prefs Teil des Projekts oder ist es Teil meiner persönlichen Eclipse-Konfiguration?Ist .settings/org.eclipse.jdt.core.prefs Teil des Projekts?
Sollte ich es zur Versionskontrolle hinzufügen?
Ja, Sie sollten. Wenn diese Datei nicht der Versionskontrolle unterliegt, können Sie keine reproduzierbaren Builds desselben Projekts erstellen, da sie nicht mehr eigenständig sind, sondern von Ihrer spezifischen Eclipse-Installation und ihren Einstellungen abhängen.
Wenn Sie dieses Projekt in einen anderen Arbeitsbereich (auf Ihrem oder einem anderen Computer) importieren, verhält es sich möglicherweise völlig anders, da die Compiler-Compliance-Einstellungen, die Compilerwarnung und vieles mehr plötzlich fehlen oder anders sind. Die Chancen stehen gut, dass ein solches Projekt im neuen Arbeitsbereich plötzlich Warnungen/Fehler anzeigt, während es vorher völlig in Ordnung war.
Hinweis: Dies erfordert auch, dass Sie tatsächlich konfigurieren alle Java-Einstellungen in den Projekteigenschaften. Verwenden Sie niemals die Java-Compilereinstellungen unter Fenster -> Einstellungen, wenn Sie eigenständige Projekte haben möchten.
Nur um ein konkretes Beispiel zu nennen: Wenn Sie die Compiler-Compliance-Ebene Ihres Projekts für Java 6 konfiguriert haben, weil Sie Java 6-spezifische Funktionen verwenden (wie Annotationen auf Schnittstellen überschreiben), wird das Projekt auf anderen Computern create a lot of compile errors.Dies liegt daran, dass die Standard-Compiler-Compliance-Stufe in jedem Eclipse-Arbeitsbereich Java 1.5 ist und in Java 1.5 die Override-Annotation einfach nicht zulässig ist.
Dies hat nichts damit zu tun, ob Sie Closed Source oder Open Source entwickeln, wie in der anderen Antwort angegeben.
Entgegen der Meinung von @ nitind, nein. Sie sollten keine IDE-spezifischen Einstellungen unter Versionskontrolle setzen. Außer Sie entwickeln IDE-Funktionen oder Plugins.
Für den Fall, dass Sie wirklich teamübergreifende IDE-Einstellungen haben, wäre es eine gute Idee, sie unter die Versionskontrolle zu stellen, aber IMO mit obligatorischen teamweiten Einstellungen ist keine gute Idee.
In allen anderen Fällen sind die gemeinsamen IDE-Einstellungen für portable Builds, selbst mit der gleichen IDE, schlecht und für Benutzer anderer IDEs bestenfalls nutzlos.
EDIT: Ich sollte unterscheiden, abhängig von der Zielgruppe Ihres Projekts. Wenn Sie ein geschlossenes Quellprodukt in einem Team entwickeln, das mit Eclipse arbeitet, ist es hilfreich und eine gute Idee, diese Einstellungen unter Versionskontrolle zu behalten. Wenn Sie eine Bibliothek, ein geschlossenes oder Open Source-Projekt oder ein Open-Source-Projekt entwickeln, überlege ich, die Präferenzen passender und höflicher zu ignorieren.
EDIT2: Ich fürchte @Bananenweizen missversteht was ich versuche zu sagen.
Ich weiß, dass diese Einstellungen die Eclipse-Compiler-Einstellungen sind. Sie sind immer noch IDE-spezifisch in dem Sinne, dass sie in Netbeans oder IntelliJ keine Wirkung haben, da sie keine Auswirkungen auf Ameisen- oder Maven-Builds von der Kommandozeile haben.
Ja, wenn Sie diese Einstellung der Versionskontrolle verlassen, können Sie viele rote Wellenlinien in Eclipse auf einer anderen Maschine bekommen. Es wird nicht, wenn es sich um ein Maven-Projekt mit einem bestimmten Quelllevel handelt, bin ich mir nicht sicher über Ameisen.
Eclipse erstellt die Projekte nicht selbst - sie erstellt sie mit Ameisen, wenn es sich um ein Eclispe- oder Ameisenprojekt handelt, oder um Maven, wenn es sich um ein Maven-Projekt handelt. Sowohl ant als auch maven haben spezifische Einstellungen für die Quellversion, die nicht von IDEs abhängig sind.
Und das ist, wo diese Einstellungen sein sollten - in der Build-Datei. Und die Build-Datei sollte unter Versionskontrolle stehen. Die Ausnahmen, die ich oben erwähnt habe, gelten immer noch.
Hier ist das Problem mit ihm unter Versionskontrolle setzen .... Wenn Sie ein Projekt importieren und öffnen, besteht darauf, Eclipse-wenn IProject.open (...) auf rührend die Datei in der aufgerufen wird, .settings-Ordner ... und das ist bevor Sie den Team-Provider für das IProject-Objekt registrieren können. Das bedeutet, dass validateEdit wird nicht Feuer und Sie bekommen ärgerliche Fehler, ob Sie klicken Sie auf "Ja" oder "Nein" auf dem Popup fragt "Möchten Sie es schreibbar machen?" Das ist gut und gut für optimistische Dateisperrdienste, aber nicht so gut für die "pessimistischen". Für uns ist das nur eine weitere eklipse Belästigung.
Wenn es an mir liegt, gibt es keine Möglichkeit Ich würde diese in der Quellcodeverwaltung setzen.
Die Antwort ist "Ja" und hier finden Sie die Motivation dafür und den richtigen Weg, es zu tun: watch the talk "Commit IDE Meta-Dateien: Missverständnisse, Missverständnisse und Lösungen." oder schauen Sie sich die entsprechende slides von EclipseCon Europe 2015 von Aurélien Pupier @apupier (Senior Software Engineer, Eclipse-Spezialist).
"Links sind fantastisch, aber sie sollten niemals die einzige Information in Ihrer Antwort sein." siehe https://meta.stackexchange.com/questions/8231/are-answers-that-just-contain-links-elsewhere-really-good-answers –
Die angegebene Datei steuert die Code-Compliance-Ebene und die Compiler-Fehler/Warnungen-Einstellungen für das Projekt, z. B. ob/wie ungenutzte Locals, private Member, nicht verwendete importierte Klassen oder nicht behandelte Nullen gemeldet werden. Es geht nicht um das Formatieren von Formatierungen, sondern darum, wie streng Sie die grundlegende Compiler-erkennbare Qualität für jeden durchsetzen wollen, der in diesem Projekt arbeitet. BEARBEITEN: Diese Datei existiert nur, weil Sie die Standardeinstellungen des Arbeitsbereichs auf der Eigenschaftsseite des Projekts überschreiben. EDIT: Es sei denn, Sie verwenden Facetten. – nitind
@nitind - Ja, du hast recht, es ist nicht so einseitig wie ich dachte. Bitte beachten Sie die Bearbeitung – kostja
Ihr Beitrag zeigt ein Missverständnis: Das sind nicht IDE-spezifische Einstellungen. Sie können in einem IDE-spezifischen Format vorliegen, aber sie sind ein wesentlicher Projektinhalt, genau wie der bekannte Klassenpfad. – Bananeweizen