Ist .settings/org.eclipse.jdt.core.einst Teil des Projekts?
Ist die Datei .settings/org.eclipse.jdt.core.prefs
Teil des Projekts, oder ist es Teil meiner persönlichen eclipse-Konfiguration?
Sollte ich es hinzufügen zu Versionskontrolle?
Du musst angemeldet sein, um einen Kommentar abzugeben.
Ja, sollten Sie. Wenn diese Datei nicht unter Versionskontrolle ist, dann kann man nicht schaffen reproduzierbare builds mit dem gleichen Projekt, denn es ist nicht mehr eigenständig, sondern hängt von der jeweiligen Eclipse-installation und Einstellungen.
Wenn Sie importieren Sie das Projekt in einen anderen Arbeitsbereich (auf Ihrer oder einer anderen Maschine), es verhält sich völlig anders, als der compiler compliance-Einstellungen, die compiler-Warnungen Konfiguration und eine Menge anderer Sachen plötzlich fehlen oder anders. Die Chancen sind hoch, dass so ein Projekt plötzlich zeigt Warnungen/Fehler in den neuen Arbeitsbereich, während es war völlig in Ordnung vor.
Hinweis: all Dies erfordert auch, dass Sie eigentlich konfigurieren Sie alle Java-bezogenen Einstellungen in den Projekteigenschaften. Verwenden Sie niemals den Java-compiler-Einstellungen unter Fenster -> "Einstellungen", wenn Sie möchten, um eigenständig Projekte.
Nur ein konkretes Beispiel: Wenn Sie so konfiguriert haben, dass Ihre Projekte compiler compliance level auf Java 6, weil Sie mit Java-6-spezifischen features (wie Überschreiben Annotationen auf Schnittstellen), dann wird das Projekt erstellen Sie auch eine Menge Fehler bei der Kompilierung auf andere Völker-Maschinen. Dies ist, weil der Standard-compiler compliance level in jedem Eclipse-workspace ist Java 1.5 und Java 1.5, die Override-annotation ist einfach nicht erlaubt.
Dies hat nichts damit zu tun, ob Sie die Entwicklung von closed source oder open source, wie in der anderen Antwort.
Im Gegensatz zu @nitind Meinung, Nein. Sollten Sie nicht, stellen Sie keine IDE-spezifische Einstellungen unter Versionskontrolle. Außer Sie entwickeln IDE-features oder plugins.
In Fall, dass Sie wirklich zwingend team-viele IDE-Einstellungen, indem Sie unter Versionskontrolle wäre eine gute Idee, aber IMO mit der obligatorischen team-systemweite Einstellungen ist nicht eine gute Idee an sich.
Für alle anderen Fälle, Gemeinschafts-IDE-Einstellungen sind schlecht für tragbare baut, auch mit dem gleichen IDE-und nutzlos, am besten für Nutzer anderer IDEs.
EDIT: ich sollte differenzieren, je nach Zielgruppe Ihres Projekts. Wenn Sie entwickeln ein closed-source-Produkt in ein team, das funktioniert mit eclipse, dann halten Sie diese Einstellungen unter version control ist hilfreich und eine gute Idee. Wenn Sie die Entwicklung einer Bibliothek, closed oder open source, oder open-source-Projekt, ich halte ignorieren die Einstellungen mehr angemessen und höflich.
EDIT2: ich fürchte, @Bananenweizen ist Missverständnis, was ich zu sagen versuche.
Ich weiß, dass diese Einstellungen in der eclipse-compiler-Einstellungen. Sie sind noch IDE-spezifische in dem Sinne, dass Sie keine Wirkung haben in Netbeans oder IntelliJ, wie Sie haben keine Auswirkungen auf ant oder maven builds von der Befehlszeile aus.
Ja, dass diese Einstellung aus der Versionskontrolle können Sie bringen zu viele rote Wellenlinien in eclipse auf einem anderen Rechner. Es wird nicht, wenn es ein maven Projekt mit einem Satz die Lautstärke der Quelle durch die Art und Weise, ich bin mir nicht sicher über ant.
Eclipse ist nicht die Projekte selbst, sondern baut Sie mit der Ameise, wenn es ein eclispe oder ein ant-Projekt, oder mit dem maven-wenn es ein maven Projekt. Beide ant-und maven-spezifischen Einstellungen für die source-version, die nicht von IDEs.
Und dies ist, wo diese Einstellungen sein sollen - in der build-Datei. Und der build-Datei sollte unter Kontrolle der Quellcodeverwaltung. Die Ausnahmen habe ich bereits erwähnt, gelten weiterhin.
Hier ist das problem mit dem setzen es unter Versionskontrolle....
Wenn Sie importieren und öffnen Sie ein Projekt, Eclipse besteht wenn IProject.open(...) wird aufgerufen auf berühren wird die Datei in der .Einstellungen-Ordner... und das ist, bevor Sie Sie registrieren können die team-provider auf die IProject-Objekt. Das bedeutet, dass validateEdit nicht Feuer und bekommen Sie ärgerliche Fehler, ob Sie auf "ja" oder "Nein" auf dem popup mit der Frage "wollen Sie machen es beschreibbar ist?" Das ist alles schön und gut für optimistisch-Datei-sperren von Providern, aber nicht so toll für die "pessimistischen" ersetzt. Für uns ist gerade noch ein weiteres eclipse ärger.
Wenn es bis zu mir, es ist keine Möglichkeit ich würde setzen Sie diese in die Quellcodeverwaltung ein.
Die Antwort ist "ja" und Sie finden hier die motivation und der richtige Weg, es zu tun: Uhr die Rede "Begehen IDE meta-Dateien: Missverständnisse, Missverständnisse und Lösungsansätze". oder schau dir die entsprechenden Folien von Der EclipseCon Europe 2015 von Aurélien Pupier @apupier (Senior Software Engineer und Eclipse-Spezialist).