2009-08-12 4 views
48

Wir verwenden normalerweise Eclipse für ein bestimmtes Java-Projekt, aber vor kurzem habe ich das Projekt in NetBeans importiert, um seine Funktionen zum Erstellen von Dialogen zu verwenden.Welche NetBeans-Projektdateien sollten in die Quellcodeverwaltung einfließen?

Da ich wahrscheinlich darauf zurückkommen werde, wollte ich die NetBeans-Projektdateien in Versionskontrolle speichern. Ich möchte jedoch keine Dateien, die "mein" oder "Projekt" sind, also Dateien mit meinen eigenen Einstellungen, die mit denen eines anderen Benutzers in Konflikt stehen, festschreiben.

NetBeans die folgende Struktur in der Top-Level-Projektgebiet erstellt.

nbbuild 
nb-build.xml 
nbproject 
    <various files> 
    configs 
    private 

Klar nbbuild ausgegeben bauen, so dass in nicht gehen Die nb-build.xml Datei scheint wahrscheinlich, da die meisten nbproject tut. Jedoch schlägt nbproject/private vor, dass es "mein" ist. Wenn ich auf "configs" schaue, ist es mir nicht klar, ob das mein oder Projekt ist ...

Hat jemand ein paar Richtlinien?

Antwort

47

Die NetBeans knowledge base article on project files & version control behandelt die NetBeans-Projektdateien, mit einem losen Hinweis darauf, welche Dateien projektspezifisch sind (d. H. Über die Versionskontrolle freigegeben werden können) und welche benutzerspezifisch sind. Hier

ist der Abschnitt über die Versionskontrolle:

Wenn das Projekt aus einem Versionskontrollsystem überprüft wird, die build (oder nbbuild), dist (oder nbdist) und die nbproject/private Ordner sollen nicht in dieses Versionskontrollsystem eingecheckt.

Wenn das Projekt unter den CVS-, Subversion- oder Mercurial-Versionskontrollsystemen läuft, werden die entsprechenden "Ignorieren" -Dateien für diese Verzeichnisse erstellt oder aktualisiert, wenn das Projekt importiert wird.

Obwohl nbproject/private ignoriert werden sollte, sollte nbproject in das Versionskontrollsystem eingecheckt werden. nbproject enthält Projektmetadaten, mit denen andere Benutzer das Projekt in NetBeans öffnen können, ohne das Projekt zuerst importieren zu müssen.

+4

Die bereitgestellte Tinte ist kaputt. Es macht diese Antwort im Wesentlichen nutzlos. – Kenneth

+2

Eine Kopie des Links finden Sie unter https://web.archive.org/web/20090216193025/http://www.netbeans.org/kb/docs/java/import-eclipse.html. – Nathan2055

+1

Was ist mit 'nbactions.xml'? –

2

Keine.

Nur Quelldateien, Build-Skripts und Dokumentation, die nicht automatisch generiert wird (z. B. die Ausgabe von Tools wie JavaDoc und Doxygen) sollten in ein Repository eingecheckt werden. Dinge wie Projektdateien, Binärdateien und generierte Dokumentation sollten nicht eingecheckt werden.

Der Grund ist zweifach. Zuerst möchten Sie die Projekteinstellungen eines anderen Entwicklers nicht mit Ihren eigenen überschreiben. Zweitens verwenden andere Entwickler möglicherweise nicht die gleiche IDE wie Sie (oder überhaupt eine IDE), also geben Sie ihnen nicht mehr als sie erstellen müssen (das Projekt oder die zugehörige Dokumentation) oder führen Sie das Projekt aus.

+9

Klar, keine Build-Ausgabe (einschließlich JavaDocs) hinzuzufügen. Aber ich bezweifle, dass die beste Antwort "keine" ist. Jeder Entwickler müsste dann allgemeine Projekteinstellungen lokal einrichten, einschließlich einfacher Dinge wie z. B. welche Quellen die Quelle sind oder auf welcher JDK-Ebene gebaut werden soll. Wenn wir diese Art von Projektinformation nicht teilen würden, würden wir Probleme bekommen. Zum Beispiel schreibe ich Code, der für 1.6 funktioniert, aber unser Projekt wird für 1.5 ausgeliefert. Ich begehe das und brich den Build. –

+0

Wenn ich ein Projekt mit Eclipse importiere, ist es für mich trivial, Quellverzeichnisse und das zu erstellende JDK zu identifizieren. Außerdem sollte es ein Build-Skript geben, das das für mich erledigt, da ich vielleicht überhaupt keine IDE verwende (sondern einen Texteditor - Notepad ++, Emacs, Vim). Jeder Job, den ich jemals benutzt habe, hat nur Source-Dateien und vom Benutzer generierte Dokumentation in das Repository eingebunden und ich habe noch nie ein Problem gesehen. –

+5

Dem stimme ich nicht zu. Ich denke, es macht die Dinge viel einfacher, wenn alle Entwickler eines Projekts die gleiche IDE und Version verwenden. Projektdateien sollten eingecheckt werden - es bedeutet, dass jeder Entwickler nicht jedes Mal, wenn er an der Quelle arbeiten muss, durch die Umgebung springen muss, um seine Umgebung einzurichten. Wenn jeder Projekte und abhängige Projekte und JARs in den gleichen Pfad oder die gleiche Pfadstruktur auscheckt, sollten sie in der Lage sein, in einem Schritt auszuprobieren und auf Build zu klicken. Zu viel Zeit verschwendet, wenn jeder ein Projekt neu konfigurieren und unterbrochene Abhängigkeiten ständig beheben muss –

19

Es stellt sich heraus, dass beide Thomas & Petercardona in gewisser Weise korrekt sind. NetBeans empfiehlt, dass Sie nur Quellcode und/oder Dokumentation importieren. Oh und die nbproject Ordner, aber nicht die * nbproject/private ** Ordner.

Vom NetBeans Knowledge Base article on importing Eclipse projects:

Versionskontrolle Überlegungen

Wenn das Projekt aus einem Versionskontrollsystem überprüft wird, der Build (oder nbbuild), dist (oder nbdist), und die nbproject/private Ordner sollten nicht in diese Versionskontrolle System überprüft werden.

Wenn das Projekt unter dem CVS ist, Subversion oder Mercurial Version Kontrollsysteme, die entsprechenden „ignorieren“ Dateien erstellt oder aktualisiert für diese Verzeichnisse, wenn das Projekt importiert wird.

Obwohl Verzeichnis nbproject/private sollte ignoriert werden, Verzeichnis nbproject sollte in das Versionskontrollsystem überprüft werden. nbproject enthält Projektmetadaten, die es anderen Benutzern ermöglichen, das -Projekt in NetBeans zu öffnen, ohne das Projekt zuerst importieren zu müssen ( ).

+2

Das ist der gleiche Link, den ich oben gepostet habe, nicht? Ich denke, es gibt einen Unterschied zwischen * nur * Quell- und * Einchecken * Projektdateien importieren. Wie ich es gelesen habe, bedeutet Ersteres, Dateien in die NetBeans-IDE zu bringen, letzteres bedeutet, Dateien in Versionskontrolle zu stellen, und enthält Projekt-Setup-Dateien. Meine Frage bezog sich auf Letzteres. Ich möchte Dateien freigeben, die steuern, wie der Build erstellt wird (standardisierte JAR-Speicherorte, jdk-Ebene), aber keine Einstellungen wie Formatierungseinstellungen, IDE-Fensterlayouts usw. steuern. –

2

Wie bei Netbeans getestet 6,8, nur die project.xml, configurations.xml und der Haupt Make-Datei (die individuell einen in dem Elternverzeichnis des 'nbproject' dir, mit Pre/Post-Zieldefinitionen) muss über das Repository verteilt werden. Alle anderen Dateien werden automatisch (neu) von Netbeans (Makefile-impl.ml, Makefile-variables.ml, alle Makefile-$CONF, Package-$CONF.bash) generiert. Das "private" Verzeichnis sollte natürlich auch ignoriert werden.