SwingApplikation.Projektumgebung
Back to current versionRestore this version

Projektumgebung #

Diese Seite ist die erste Folge einer Artikelserie zur Erstellung einer Swing Applikation. Als erstes benötigen wir eine Infrastruktur zum Austausch unserer Daten im Projektteam. Außerdem müssen wir uns auf eine IDE einigen.

gemeinsames Wiki #

Wir benutzen das LUG-Wiki für unser Beispielprojekt. Leider funktioniert das Einloggen nicht mehr so, wie auf der Startseite angegeben (Hallo Peter!). Hierzu kann man oben rechts auf "meine Einstellungen" klicken und dann die angegebene IP-Adresse durch einen Wiki-Namen ersetzen. Danach taucht am oberen Rand der Wiki-Texte ein neuer "Bearbeiten"-Button auf. Ab jetzt können wir Informationen austauschen.

Austausch von Dateien #

Der vermeintlich einfachste Weg ist, tar-Archive zu erzeugen und herumzusenden. Hat ein Projekt aber mehr als einen Benutzer, entsteht so schnell ein Durcheinander, weil mehrere Teilnehmer gleichzeitig Änderungen vornehmen wollen. Dafür gibt es Versions-Kontrollsysteme (VCS, siehe auch VersionsVerwaltung) wie CVS (KurzAnleitungCVS), SubVersion, Bazaar, GIT oder Mercurial (siehe auch MercurialVersionControlServer).

Die neueste Generation der VCS arbeitet dezentral, d.h. jeder Projektteilnehmer hat für sich selber eine vollständige Version des gesamten Repositories. Dann können später einzelne sog. "changesets", d.h. Änderungs-Sätze ausgetauscht werden, bis beide Repositories wieder synchronisiert sind. Bei den dezentralen VCS gibt es als bekannteste Vertreter Bazaar, GIT oder Mercurial. ThomasBayen hat sich im Frühjahr 2009 nach einiger Recherche für Mercurial entschieden, das am weitesten verbreitet zu sein scheint. Außerdem gibt es ein halbwegs vernünftiges Eclipse-Plugin.

Ja, genau: Laut Vergleich Mercurial vs. GIT scheint mir Mercurial hier die passende Wahl zu sein. --MarkusMonderkamp

Eine deutsche Erklärung zu Mercurial: http://intevation.net/~thomas/mercurial-lt2006/#id2452004 -- ThomasThiessen

Mercurial kann man in einem Debian-System installieren mit 

  aptitude install mercurial

einige Mercurial-Befehle: 

  hg clone ssh://username@hg.javaproject.de/../groups/mercurial/repos/meinprojekt meinprojekt

Holt das angegebene Repository vom angegebenen Server. Es entsteht ein neues Verzeichnis "meinprojekt", in dem man dann arbeiten kann.

Die weiteren Befehle innerhalb des Repositories ausführen: 

  hg status

Zeigt von mir selber geänderte Dateien (vorne 'M') und neue Dateien (vorne '?') an. 

  hg add

Nimmt alle neue Dateien in die Versionsverwaltung auf. Beachtet dabei die Filter-Einstellungen in ".hgignore". 

  hg commit -m "texttexttext"

Schreibt alle Änderungen in das lokale Repository. 

  hg outgoing ssh://tbayen@hg.javaproject.de/../groups/mercurial/repos/meinprojekt

Zeigt die ausgehenden Unterschiede zwischen dem Repository auf dem Server und meinem eigenen Repository (d.h. dem ,was ich mit commit auch eingecheckt habe) an. 

  hg incoming ssh://tbayen@hg.javaproject.de/../groups/mercurial/repos/meinprojekt

Wie outgoing, zeigt aber die neuen Änderungen auf dem Server an.

Diesen Befehl wieder eine Verzeichnisebene oberhalb des Repositories ausführen: 

  hg push ssh://username@hg.javaproject.de/../groups/mercurial/repos/meinprojekt

schreibt alle Änderungen aus dem lokalen Repository in das entfernte Repository auf dem Server hg.javaproject.de, auf dem ich einen SSH-Zugang habe.

Entwicklungsumgebung Eclipse #

Wir haben uns auf die EclipseIDE als Entwicklungsumgebung (IDE) geeinigt. Dies hauptsächlich, weil wir bisher einige Erfahrungen damit haben. Eine gute und auch freie Alternative ist auch Netbeans (siehe auch NetbeansVsEclipse).

Wir benutzen folgende Plugins, deren Installation ggf. auf EclipsePlugins näher beschrieben ist:

Das Mercurial Plugin ist eigentlich nicht unbedingt nötig. Man kann Mercurial auch von der Kommandozeile aus bedienen, wenn man das möchte. Über das Plugin ist es halt etwas komfortabler.

Das M2Plugin (für Maven) ist eigentlich ein Muss, weil ohne dieses die Auflösung von Abhängigkeiten nicht in den Eclipse-Classpath übernommen würde. Es gibt zwar ein reguläres Maven-Plugin namens "eclipse:eclipse", das grundsätzlich auch funktionieren würde, das aber mit M2Eclipse nicht sonderlich kompatibel ist. Es müsssten sich also alle Teammitglieder für die gleiche Lösung entscheiden und M2 ist recht komfortabel, wenn es einmal installiert ist.

Ich habe das vorhandene Projekt folgendermassen in Eclipse eingebunden: Ich das Projekt per mercurial in einen vorhandenen Eclipse-Workspace ausgecheckt. Dann habe ich in Eclipse "File -> New -> Java Project" ausgewählt. Dann habe ich den Namen meines Projektverzeichnisses angegeben und in diesem sowie dem folgenden Wizard-Fenster auf "Weiter" bzw. "Finish" geklickt. Eclipse hat dabei dann eben kein neues Projekt angelegt, sondern mein vorhandenes so wie es ist eingebunden.

noch offene Themen #