You are here: Foswiki>ITServicesInfo Web>Anleitungen>ProgrammierpraxisWINEME (02 Dec 2010, TimmWunderlich)Edit Attach

Programming@WINEME Best Practice

Subversion(SVN) ist eine OpenSource -Versionierungssystem, daß am Lehrstuhl Wirtschaftsinformatik und Neue Medien der Universität Siegen eingesetzt wird. Es gilt als technische Weiterentwicklung des Concurrent Versioning Systems(CVS), wurde aber unabhängig von diesem entwickelt. Es gibt derzeit mehrere Methoden auf das Versionierungssystem zu zugreifen. Einerseits über einen SVN-Client, der weder als Stayonly-Anwendung oder integriert in die Entwicklungsumgebung genutzt werden kann. Es hat sich in der Praxis gezeigt, dass das Subversive -Plugin für Eclipse deutlich zu verlässiger, stabiler und praxistauglicher ist, als die Alternative Subclipse. Die Benutzung von Subversive wird deshalb im Eclipse-Umfeld dringend empfohlen, auch wenn man durch die Namensähnlichkeit eher geneigt ist Subclipse zu installieren.

Alternative kann man auch über das Webinterface auf die aktuellen Versionen der Repositories zu greifen. Ein Repository ist eine Ordner in dem ein einzelnes Projekt verwaltet wird. Allerdings kann bei der Arbeit über eine Webbrowser nur einzelne Dateien herunterladen. Deshalb kann das SVN auch über WebDAV in allen aktuellen Betriebssystemen als Dateisystem eingehängt werde. Derzeit dieser Zugriff nur lesend möglich. Gerade beim häufigen Zugriff auf Einzeldateien außerhalb des Kontextes eine Entwicklungsumgebung, wäre ein solches Einhängen des SVN ins das eigene Dateisystem mit Lese- und Schreibzugriff sehr sinnvoll. Möglicherweise folgt diese Möglichkeit in nächster Zeit.

Zugang zu unseren Repositories

URL: https://wineme.fb5.uni-siegen.de/subversion/"NameDesRepositories"

Repo oder Berechtigungen auf exitierende Repos: Gibt es vom IT-Team (wineme-it@uni-siegen.de)

Anmelden mit WiNeMe Benutzernamen

Übersicht über die Repositories

URL: https://wineme.fb5.uni-siegen.de/websvn/

Anmelden mit WiNeMe Benutzernamen

Installation eines Projektes (am Beispiel der EUSOP Plattform):

Im folgenden wir am Beispiel der EUSOP-Plattform demonstriert, wie man selbige mittels des Subversive Plugins in die Eclipse Entwicklungsumgebung integriert und welche Probleme und Hürden dabei auftreten können(sollten weitere Hürden auftreten sollten diese in diesem Dokument nachgetragen werden). Es sollte nur in absoluten Ausnahmenfällen manuell eine Eclipse-Plugin in den Plugin-Ordner von Eclipse kopiert werden. Eclipse hat seit Version 3.2. ein integiertes Plugin-Distributionssystem(Callisto/Europa). Sollten in diesem benötigtete Pakete fehlen, sollten diese nur über einen externen Update-Link nachgeladen werden( bitte nur über Help->Software Update-Find and install->Search for new features->New Remote Site).

Notwendige Software für die EUSOP-Plattform:

  • Eclipse 3.2.0(Callisto) oder größer(Europa o.ä.)

  • Subversive (über Update-Link von der Hersteller Homepage nachladen)

  • Java 1.5 (sonst gibt es kompatibilitätsprobleme mit anderen Paket...versprochen!!!)

  • EUSOP-Server(Version Marcus), dieser enthält:

    • Tomcat 5.5

    • Axis 2.0

    • ActiveBPELEngine 2.0 mit Axis 1.2

    • jUDDI

    • DerbyDB

  • Optional kann das die WST und die J2EE -Unterstützung aus Callisto/Europa ( bitte nur über Help->Software Update-Find and install->Search for new features->Callisto/Europa Discovery Site) installiert werden

Sind alle Komponenten installiert, kann mit den Auschecken des EUSOP-Codes begonnen werden.

Dazu legt man in der Java-Sicht von Eclipse zuerst eine JAVA-PROJEKT an (wird das Projekt einfach in eine neues Eclipse Projekt ausgecheckt kommt es zu gravierenden Fehlermeldungen). Wählen Sie Java 1.5 als VM aus und wählen Sie das Quellcode und Binaries in den selben Ordner liegen sollen.

Anschliessend wählt man im Menü File->New->Others und dort in der Kategorie SVN->Projects

from SVN. Man klickt auf Next, wählt im nächsten Dialog Create a new repository location, trägt dort die Daten notwendigen Daten ein und klickt wiederum auf Next. Im nächsten Dialog wählt man die Ordner und Dateien, die unter halb von (nicht den Ordner selber!!!) Root->SOA-Projektgruppe->trunk->SOA-Framework liegen. Importiert man den Ordner SOA-Framework, anstatt der Inhalte diese Ordners, dann gibt es Probleme beim Kompilieren. Man klickt auf Finish und wartet bis der Code heruntergeladen wurde. Abschließend importiert man über Project->Properties->Java Code Path->Libraries die Eclipse Library Junit4 und als externe JARs die tools.jar auf dem Library-Ordner des jdk-1.5.0 und die jars die sich im shared-Ordner des SOA-Server(Version Markus) finden.

Somit sollte der Code der EUSOP-Plattform in Eclipse integiert sein.

Veröffentlichung eines eigenen Projektes im Versionierungsssystem:

Man klickt m mit der rechten Maustaste auf sein noch nicht publiziertes Projekt. Dort auf Team->Share project->SVN. Wählt dann die Repository-Location oder legt Sie neu an. Man wählte Use project name und use multiple projects layout. Damit wird sichergestellt, dass mehrere Projekte übersichtlich im SVN koexistieren können. Anschliessend wird eine sinnvoller Projektkommentar abgegeben.

Allgemeiner Umgang mit dem SVN:

Um Fehler oder Störungen des Versionierungssystems zu vermeiden, sollten einige Kleinigkeiten berücksichtigt werden:
  1. Immer aktuell bleiben: Man sollte regalmässig ein Update ziehen.

  2. Immer erst updaten und erst dann kommiten, sonst kann es zu Synchronisierungsproblemen kommen

  3. Sollte gar nichts mehr gehen, dann eine kommten check out der Repositories ziehen, so das man die letzte volständige Version aus dem Versionierungssystem bekommt.

  4. Keine Ordnernamen im Code verwenden, die andere nicht auf ihrem Rechner oder einem andersartigen Betriebsystem haben. Im Zweifelsfall ist es recht egoistisch, eine auf sein System angepasste Version ins Versionierungssystem ein zu checken.

Allgemeine Tipps und Erfahrungen:

  • 80/20 oder „Das ist fast fertig“

    Was auffällt ist das IT-Projekte unterschätzt werden. Wenn erzählt wird man sei fast fertig, kannst man sicher sein, dass alle Unit-Tests, jegliche Dokumentation und jegliche Praxistests nicht durchgeführt worden sind. Allgemein gilt, wenn die 80% erreicht sind, das die restlichen 20% des Projektes 80% der Gesamtressourcen in Anspruch nehmen. Also „Keep it simple, but smart“

  • Schau Euch in diesem Konetxt aus das an!

    Jeder der sich die Zeit nehmen wird, sich mit Eurem Programmierprojekt auseinander zu setzen verfolgt einzig und allein persönliche Interessen. Wenn man Euch Vorschläge macht noch andere Aspekte eines Themas zu betrachten, öffnet Euch für neue Ideen, aber hütet Euch im Kontext fremder Interessen schamlos ausnutzen zu lassen

  • First update, than commit

    Zur Versionierungpraxis: Eigentlich kann man mit den meisten Versionierungssystemen recht wenig falsch machen. Kurze Patches. Vor jedem Commit und zu Beginn jeder Programmiersession immer ein Update laden. Bei großen Patches immer die Gruppe zu einem expliziten Update z,B. per Email auffordern

  • Nachhaltigkeit

    Nachhaltigkeit wir eigentlich immer belächelt. In einem Programmierprojekt denkt jeder, an heute und niemand an morgen. Trotz aller Versprechen, werden eher drei neue Patches eingepflegt, als 3 Zeilen zu dokumentieren oder zu testen. Es gibt 2 Möglichkeiten de Problem entgegen zu treten:

    1. Es gibt in Programmierteam einen, der sich ausschließlich um Dokumentation, Tests, Wiederverwendbarkeit und Lesbarkeit der Programmierprojektes kümmert. Diesen Job will meistens keiner machen. Gerade deswegen sollte diese Aufgabe mehr gewürdigt und belohnt werden als jeder Programmierjob.

    2. Nachhaltigkeitstage: Fixiert im Projektplan Tage, an denen nur dokumentiert, getestet und überarbeitet wird, aber keine neuen Funktionen dazukommen. Wer an solchen Tagen verhindert oder trotzdem programmiert, soll ruhig dafür geächtet werden.

  • Spezialisierungsvorteile

    Oft gibt es in Programmierprojekten Spezialisten oder Ideen, die im Sinne des kleinsten gemeinsamen Nenners im Projekt untergehen, weil man oftmals nicht über den eigenen Tellerrand hinausschauen will. Fördert außergewöhnliche Ideen und Talent anstatt diese zusätzlichen Ressourcen verpuffen zu lassen. Gebt den Leuten auch Zeit eigenen Ideen nachzugehen, auch wenn Sie nur indirekt das Projektziel fördern. Die Motivation der Gruppemitgleider wird sich erhöhen und möglicherweise wird es ungeahnte Synergien nach sich ziehen.

  • Wiederverwendung ja, aber nicht um jeden Preis

    Code anderer Leute wiederzuverwenden ist super, aber wenn sich dadurch die Zeit für einen Test, einen Funktionsaufruf oder die Ressourcenbelegung deutlich vervielfacht ist die Frage, ob Wiederverwendung bei sinnvoll ist durchaus gegeben.

-- MoritzWeber - 02 Aug 2007
Topic revision: r3 - 02 Dec 2010, TimmWunderlich
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback