Wie gehst du mit verschiedenen Java IDEs und svn um?

Die clevere Antwort lautet "so" - wenn Sie nicht mit mehreren IDEs arbeiten, wissen Sie nicht, ob Sie wirklich darauf vorbereitet sind, mit mehreren IDEs zu arbeiten. Ehrlich. :)

Ich habe immer mehrere Plattformen als umständlicher angesehen, da sie unterschiedliche Kodierungsstandards verwenden können (zB Windows kann standardmäßig ISO-8859-1, Linux zu UTF-8 verwenden) - für mich hat Kodierung viel mehr Probleme verursacht als IDEs.

Einige weitere Hinweise:

• Vielleicht möchten Sie mit Maven ( Ссылка ) gehen, IDE-spezifische Dateien generieren lassen und sie niemals an die Quellcodeverwaltung binden.
• Um sicher zu sein, dass Sie die richtigen Artefakte erzeugen, sollten Sie einen dedizierten Server erstellen, um Ihre Ergebnisse (z. B. cruisecontrol) entweder mit Hilfe von Ameise, Maven oder einem anderen Werkzeug zu erstellen. Diese Ergebnisse sind diejenigen, die außerhalb von Entwicklungsmaschinen getestet werden. Eine großartige Möglichkeit, Menschen bewusst zu machen, dass es eine andere Welt außerhalb ihrer eigenen Maschine gibt.
• Verhindern, dass ein maschinenspezifischer Pfad in einer IDE-spezifischen Datei in der Quellcodeverwaltung enthalten ist. Verweisen Sie externe Bibliotheken immer nach logischen Pfadnamen, vorzugsweise mit ihrer Version (wenn Sie maven nicht verwenden)

Wir unterhalten momentan sogar ein Netbeans und ein Eclipse-Projekt für unseren Code in SVN, ohne irgendwelche Probleme. Die Netbeans-Dateien treten nicht auf die Eclipse-Dateien. Wir haben unsere Projekte so strukturiert:

Die größten Punkte scheinen zu sein:

• Verbieten Sie absolute Pfade in der Projektdateien für beide IDE.
• Legen Sie fest, dass die Projektdateien ausgegeben werden sollen Klassendateien in dasselbe Verzeichnis.
• svn: ignoriere das Private Verzeichnis im .nbproject Verzeichnis.
• svn: Ignoriere das Verzeichnis für Klassendatei-Ausgabe von den IDEs und anderen von der Laufzeit generierten Verzeichnissen wie dem obigen Verzeichnis logs.
• Lassen Sie Leute beide konsistent verwenden so dass Unterschiede gelöst werden schnell.
• Pflegen Sie auch ein Build-System unabhängig von den IDEs wie Cruisecontrol.
• Verwenden Sie UTF-8 und korrigieren Sie alle Codierungsprobleme sofort.

Wir entwickeln unter Fedora 9 32-Bit und 64-Bit, Vista und WindowsXP und ungefähr die Hälfte der Entwickler verwendet eine IDE oder die andere. Einige benutzen beide und wechseln regelmäßig hin und her.

Am besten ist es wahrscheinlich, nicht eine IDE-bezogene Datei (wie Eclipse .project) zu schreiben, so dass jeder das Projekt auschecken und sein Ding so machen kann, wie er will.

Davon abgesehen denke ich, dass die meisten IDEs ihr eigenes Konfigurationsdateischema haben, also könnt ihr es vielleicht ohne einen Konflikt machen, aber es fühlt sich unordentlich an.

In den meisten Fällen stimme ich mit seldaek überein, aber ich neige auch zu der Aussage, dass Sie zumindest eine Datei angeben sollten, die angibt, welche Abhängigkeiten, welche Java-Version zum Kompilieren etc. usw. erforderlich sind dass ein NetBeans / Eclipse-Entwickler möglicherweise in ihrer IDE kompilieren muss.

Wir benutzen zur Zeit nur Eclipse und so schreiben wir alle Eclipse .classpath .project Dateien nach svn, was meiner Meinung nach die bessere Lösung ist, da dann jeder Fehler reproduzieren kann und nicht einfach mit IDE Details herumfuchteln kann.

Ich bin der Philosophie, dass der Build mit einem "kleinsten gemeinsamen Nenner" -Ansatz gemacht werden sollte. Was in die Quellcodeverwaltung einfließt, ist erforderlich, um den Build zu erstellen. Während ich ausschließlich mit Eclipse entwickle, ist mein Build mit ant in der Kommandozeile.

In Bezug auf die Quellcodeverwaltung checke ich nur Dateien ein, die für den Build von der Befehlszeile aus wichtig sind. Keine Eclipse-Dateien. Wenn ich eine neue Entwicklungsmaschine einrichte (scheint zweimal pro Jahr), ist es ein wenig mühsam, Eclipse dazu zu bringen, das Projekt aus einer Ameise zu importieren, aber nichts Unheimliches. (In der Theorie sollte dies das gleiche für andere IDEs funktionieren, nein? Sie müssen in der Lage sein, von der Ameise zu importieren?)

Ich habe auch dokumentiert, wie man eine reine Build-Umgebung aufbaut.

Ich benutze Maven und checke nur die Pom & amp; Quelle.
Nachdem ich ein Projekt ausgecheckt habe, starte ich mvn eclipse: eclipse
Ich sage Svn, das generierte Projekt usw. zu ignorieren.

Folgendes mache ich:

1. Behalten Sie in der Quellcodeverwaltung nur Ihr Ameisen-Build-Skript und den zugehörigen Klassenpfad bei. Classpath könnte entweder explizit im ant-Skript, einer Eigenschaftendatei oder von efeu verwaltet werden.
2. schreibe ein ant-Ziel, um die Eclipse-Datei .classpath aus dem ant-Klassenpfad
zu generieren
3. Netbeans verwenden Ihr Build-Skript und Ihren Klassenpfad, konfigurieren Sie es einfach über ein freies Formular-Projekt.

Auf diese Weise erhalten Sie IDE-unabhängige Build-Skripte und glückliche Entwickler:)

Es gibt einen Blog auf der Netbeans-Seite, wie man 3. macht, aber ich kann es jetzt nicht finden. Ich habe einige Hinweise dazu, wie das oben auf meiner Website zu tun - Link-Text (schnell und hässlich, tut mir leid)

Beachten Sie, dass Sie bei Verwendung von Ivy (eine gute Idee) und Eclipse versucht sein könnten, das Eclipse-Efeu-Plugin zu verwenden. Ich habe es benutzt und fand es fürchterlich fehlerhaft und unzuverlässig. Besser zu verwenden 2. oben.