Multi-IDE-Unterstützung in Java für ein Team

Ich denke, der beste Weg ist, den Build-Prozess unabhängig von der IDE zu machen. Das bedeutet, dass Ihr Projekt nicht auf IDE-spezifischen Dateien aufbauen sollte, sondern auf einem externen Build-System wie Apache Maven , Apache Ant , oder machen Sie selbst oder benutzerdefinierte Skripte. Maven wird von den meisten gängigen Java IDEs unterstützt, entweder direkt oder über Plug-Ins.

Wenn Sie keine externen Build-Systeme verwenden möchten, sollten Sie das Projekt zumindest so einfach wie möglich einrichten (z. B. mit Standardordnern für gemeinsam genutzte Bibliotheken und anderen Abhängigkeiten). Wenn ich in der Vergangenheit an Teams mit mehreren IDEs gearbeitet habe, verbrachte ich mit Abstand die meiste Zeit damit, Abhängigkeiten aufzulösen, da sich die Voraussetzungen für die Entwicklung des Projekts im Laufe der Zeit änderten. Im schlimmsten Fall könnte es sogar passieren, dass Entwickler nicht mehr die neueste Version aus dem Repository für die Versionskontrolle abrufen, da sie der Meinung sind, dass das Einrichten eines neuen Projekts so problematisch ist.

Wenn Ihr Projekt viele Bibliotheksabhängigkeiten aufweist, ist es eine gute Idee, diese im Repository der Versionskontrolle in binärer Form zur Verfügung zu stellen. Auf diese Weise müssen die Leute nicht alle Abhängigkeiten der Abhängigkeiten auflösen und so weiter, nur um ein einzelnes Projekt zu erstellen. Dies erfordert jedoch, dass Sie jemanden haben, der dafür verantwortlich ist, die "offiziellen" Binärdateien auf dem neuesten Stand zu halten, wenn sie sich ändern. (Dies ist im Wesentlichen die gleiche Philosophie, die vom Maven-Repository verwendet wird, aber die Prinzipien können auch manuell angewandt werden, wenn Maven nicht verwendet wird.)

Nun, das ist eine ziemlich selbstbeantwortete Frage.

Die Dateien, die nicht in die Quellcodeverwaltung einchecken, sind Dateien, die mit den IDEs selbst zu tun haben.

Überlassen Sie es den Entwicklern, diese Dateien zu generieren.

Wenn Sie Maven verwenden, kann es die Dateien wie Eclipse .project und .classpath für Sie erzeugen. Eclipse ist im Allgemeinen sehr einfach mit einer einfachen Dateistruktur (mit der neuen Option Java Project ) zu verwenden.

Ich denke, Maven hat auch Netbeans-Unterstützung, ich bin mir nicht sicher, ob es IntelliJ gibt.

Maven's Seite ist maven.apache.org .

Für jede IDE, die mehr als einen Entwickler hat, checken Sie alle unterstützenden Dateien ein. Warum erfinden Sie das Rad an jedem Schreibtisch neu.

Ich habe dies mit vielen verschiedenen IDEs gemacht, und ich muss noch einen Dateinamenkonflikt sehen.

Auch wenn nur ein einziger Entwickler eine bestimmte IDE verwendet, ist es in der Tat vorteilhaft, die unterstützenden Dateien zu versionieren, aus demselben Grund, aus dem Sie die anderen Dateien in Ihrer Entwicklungsumgebung versionieren: history, diffing, comments usw.

Für Eclipse wären das .classpath- und .project-Dateien.

Mein Team benutzt Maven, und Entwickler werden davon abgeraten, Eclipse-spezifische Dateien einzusehen. Da sie aus Maven generiert werden können, sind diese Dateien redundant.

Auch das Überprüfen von projektspezifischen Dateien scheint Zeit zu sparen, ist aber meistens ein Problem, da die Workstations der Entwickler voneinander abweichen und Konflikte in den IDE-spezifischen Dateien vermieden werden können. Die einzige Möglichkeit, dies zu umgehen, ist, jeden dazu zu bringen, seine Umgebung auf die gleiche Weise einzurichten, was dem IDE-agnostischen Ansatz widerspricht.

Es gibt viele Überlegungen bei der Verwendung mehrerer Toolsets innerhalb desselben Projektteams. Zum Beispiel hat mein Team Java-Entwickler, die IntelliJ verwenden, und die meisten Frontend-Entwickler (JSP / CSS / HTML), die Eclipse verwenden. Wir sind dabei, die Eclipse-Benutzer zu IntelliJ zu migrieren, da wir einige IntelliJ-Plugins entwickelt haben, die erweiterte Unterstützung für unsere Umgebung bieten. Wir werden die Plugins nicht für mehrere Plattformen entwickeln, daher standardisieren wir auf der ganzen Linie IntelliJ.

In Bezug auf bestimmte Dateien kann ich mit IntelliJ sprechen. Wir haben unsere .ipr-Dateien und unsere .iml-Dateien eingecheckt. Überprüfen Sie nicht die .iws-Dateien. Wenn Sie auch Eclipse-Benutzer haben, konfigurieren Sie Ihr IntelliJ-Projekt zum Lesen / Speichern von Abhängigkeitsinformationen in der Datei .classpath und übergeben Sie diese an Ihr VCS.

Wir unterstützen absichtlich mehrere IDEs aus demselben SVN-Repository. Unser Gedanke war, dass wir sicherstellen wollten, dass, wenn eine neue Person dem Team beitrat oder jemand an einer neuen Maschine arbeiten musste, sie die Codebasis auschecken, in die IDE importieren und sofort eine Arbeit haben wollten. fähige Konfiguration.

Das heißt auf der Entwicklerseite, dass sie ihre Änderungen an den IDE-Dateien nicht committen sollten. Alles andere (z. B. src, test, lib usw.) wird zur Gruppe, die wir normalerweise jeden Tag aktualisieren und festschreiben.

Der Nebeneffekt ist, dass wir die IDE-Kriege hier vollständig beseitigt haben: Netbeans und Eclipse-Leute leben in perfekter Harmonie (schauen die IntelliJ-Leute schief an, aber hey ...; -).

Weitere Kommentare und Antworten zu diesem Thema finden Sie unter diese Frage (Wie gehen Sie mit verschiedenen Java-IDEs und svn um?)

Wir benennen unsere IDE-Dateien zum Einchecken mit einer zusätzlichen Erweiterung .deletethis oder ähnlich um. Wenn eine neue Person das Projekt auscheckt, streichen sie einfach die zusätzliche Erweiterung und sind gut zu gehen. Auf diese Weise vermeiden wir Quellcodeverwaltungskonflikte mit den Projektdateien, da die Benutzer ihre Umgebung optimieren. Und Sie müssen sich keine Gedanken darüber machen, neue Entwickler dazu zu bringen, diese Dateien nicht einzulesen.

Normalerweise würde ich das für eine schlechte Idee halten. Ich bin mir nicht sicher, welche Art von Umgebung das ist (vielleicht Open-Source?), Aber es wäre wirklich scheiße, mehrere IDEs zu unterstützen. Eine Sache, die ich empfehlen würde, wenn dies unvermeidlich ist, wäre, Ihre Builds in Ant-Skripten zu standardisieren. Wenn Sie eine große Anzahl von Abhängigkeiten haben, kann dies der einfachste Weg sein, um einen vorhersehbaren Build für alle Plattformen zu erhalten.

Wenn eine der IDEs RAD ist (basierend auf Eclipse), gibt es einen ganzen Ordner namens .settings, den Sie nicht in den SCM aufnehmen möchten.