View Attach Info

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 - Versionskontrolle #

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 MercurialVersionControl).

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

Die wichtigsten Befehle sind auf der Seite MercurialVersionControl verzeichnet.

Unser Beispielprojekt gibts mit folgendem Befehl 

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

Projektverwaltung #

Seit der breiteren Benutzung von Maven gibt es einige Leute, die es für nötig erachten, eine Projektverwaltung einzusetzen. Faktisch benutzen die meisten dieses jedoch wie "Ant auf Speed" und heben dann noch das Abhängigkeitsmanagement sowie die Fähigkeit hervor, eine Webseite zu erstellen. Der Unterschied liegt aber eigentlich nicht in den Features, sondern in der Philosophie: Ein Ant-Skript beschreibt, was man tun will, eine Maven-Konfiguration beschreibt, welche Dateien man hat und welche Artefakte man erzeugen will. Die eigentliche Arbeit wird dann von Maven-Plugins erledigt. Nach einigen Erfahrungen mit Maven kann ich dazu nur sagen, daß Maven auch nicht die Erwartungen erfüllt, die man in es setzt. Hält man sich in seinem Projekt an die Maven-Konventionen und verlangt keine Extrawürste, hat Maven den Vorteil, daß man immer schön standardisiert arbeitet. Aber mal ehrlich: Das kann Ant auch! Dafür bietet Ant jedoch die Möglichkeit, eigene Extrawürste zu programmieren, während das bei Maven nicht nur ungleich komplizierter ist, sondern auch grundlegend gegen die Philosophie verstößt.

Projektverwaltung mit ApacheAnt #

Ich habe mir ein eigenes Ant-Skript geschrieben, das ich FlyingAnt genannt habe. Einige der Grundüberlegungen hierzu habe ich auf der Seite ApacheAnt niedergeschrieben. Die ursprüngliche Version benutzte FreeMarker als Template-Engine, um aus einer Menge von Templates anhand einer Konfigurations-Datei ein passendes, auf das Projekt abgestimmtes, Ant-Skript zu erzeugen. Der erste Pass war nötig, da Ant keine echte Programmiersprache bietet und bei der dynamischen Konfiguration oft an Grenzen stößt. Das funktionierte sehr gut und wurde von mir in mehreren Projekten benutzt.

In der neuen Version habe cih den recht lästigen ersten Pass weggelassen und die benötigten dynamischen Anteile innerhalb von Ant-Tasks in Groovy programmiert. Die AntGroovyIntegration ist ein sehr praktischer Weg, beide Welten zu verbinden. Das Ant-Skript läuft wie bisher in unterschiedlichsten IDE-Umgebungen, kann aber im Grunde beliebig komplexen Code enthalten.

Mein Ant-Skript kann Bibliotheks-Abhängigkeiten auflösen (mit Hilfe von Ivy), erstellt automatisch eine Webseite (siehe http://lugframework.javaproject.de) und was das wichtigste ist: Jeder halbwegs Ant-erfahrene Benutzer kann die Tasks, die ihm wichtig sind, anpassen, wie er möchte.

Projektverwaltung mit Maven 2 #

Maven ist ein Projektmanagement-Tool für Java. Es ist zum einen ein Ersatz für ApacheAnt, weil es die meisten einfachen Ant-Buildskripte ersetzt. Man benutzt dort sogenannte Plugins, die man mit standardisierten Befehlen startet und die ggf. automatisch heruntergeladen nud augeführt werden. Einer der vielgerühmten Vorteile von Maven ist das Abhängigkeitsmanagement, d.h. man hat eine Art Paketmanager für JAR-Bibliotheken. Das funktioniert ganz gut (solange die Bibliotheken mit einer ordentlichen POM-Datei versehen und ins zentrale Repository eingestellt wurden). Eine andere bekannte Eigenschaft ist, daß Maven es sehr einfach macht, automatisch Webseiten zu einem Projekt zu erzeugen.

Maven2 gibts unter http://maven.apache.org/. Ich habe es über das Debian-Paket "maven2" installiert.

Projektverwaltung mit Gradle #

Eine andere und modernere Alternative ist Gradle. Es baut auf Groovy auf und bietet die von Groovy als Skriptsprache gewohnte riesige Flexibilität bei der gleichzeitigen Übernahme einiger sinnvoller Konzepte von Maven. Zum Vergleich mit Maven kann man z.B. sehen, warum Hibernate sich für Gradle entschieden hat: http://community.jboss.org/wiki/Gradlewhy und http://community.jboss.org/wiki/MavenProblems

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. Zur Passwort-Eingabe benötigt es übrigens noch das Debian-Paket ssh-askpass.

Das M2Plugin (für Maven) ist eigentlich ein Muss, weil ohne dieses die Auflösung von Abhängigkeiten (um die es bei Maven ja geht) 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.

arbeiten mit Mercurial unter Eclipse #

Um ein Projekt in Eclipse zu laden, gibt es zwei Methoden:

Ich habe ein vorhandenes (bereits über die Kommandozeile ausgechecktes) Projekt folgendermassen in Eclipse eingebunden: Ich habe 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.

Um ein Projekt per Mercurial direkt vom Server herunterzuladen, habe ich unter "File -> New -> Project..." Die Auswahl "Mercurial -> Clone Repository using MercurialEclipse" getroffen. Unter URL habe ich "ssh://hg.javaproject.de/../groups/mercurial/repos/swingapplikation" und unter Username meinen SSH-Accountnamen eingegeben. Nach einem Klick auf "Finish" ist dann schon bald ein neues Projekt erzeugt.

Habe ich ein Projekt geändert, kann ich über das Kontextmenü auf dem Projektnamen im Package Explorer mit "Team -> Commit..." das Commit-Fenster aufrufen. Dort gebe ich einen sinnvollen Kommentar zu meiner Bearbeitung an, wähle u.U. unten in der Liste die Dateien aus, die ich committen möchte und kann dann mit "OK" die Änderung committen. Nun ist die Änderung in meinem lokalen Repository verzeichnet.

Um diese Änderung nun in ein anderes Repository (z.B. den ursprünglichen Server im Internet) zu committen, rufe ich "Team -> Push..." auf. Dort gebe ich die URL vom herunterladen ein (ist nur einmal nötig, dann merkt sich Eclipse den Wert). Mit "Finish" werden nun die Daten übertragen.

Wer Änderungen vom Internet-Server holen will, muss diese zuerst mit "Pull" in sein lokales Repository holen. Dann kann man sie mit Update in die Arbeitskopie übernehmen (ist normalerweise automatisch eingestellt).

noch offene Themen #

Tags:  VersionsVerwaltung, Eclipse

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-13) was last changed on 08-Apr-2011 11:57 by ThomasBayen