Posts mit dem Label SVN werden angezeigt. Alle Posts anzeigen
Posts mit dem Label SVN werden angezeigt. Alle Posts anzeigen

Montag, 11. Juli 2011

SVN Server aufsetzen

Codemanagement ist ein Grundbaustein fürs Projektmanagement. Die meisten Unternehmen betreiben eigene Server fürs Codemanagement. Mache sogar Mehrere. Aber auch hier gilt, viel hilft nicht viel. Private Projekte liegen oft bei Sorce Forge oder ähnlichen Anbietern. Aber man kann auch in 5 Minuten einen eigenen Server fürs Codemanagement aufsetzen. Im Internet gibt es eine Vielzahl von mehr oder weniger guten Anleitungen:

Aber es geht noch schneller:

Donnerstag, 25. November 2010

Au weia, ich habe die falsche Datei überschrieben ...

was nun, ich habe eine wichtige Datei im Projekt überschrieben und im Subversion liegt auch nur eine alte Version. Eclipse liegt lokale Kopien von den Daten an die man bearbeitet. Wenn man eine solche lokale Kopie wiederherstellen will, muss man im Package Explorer einen Rechtsklick auf die Datei machen und dann in das Menü Restore from Local History ... (siehe Bild).
Damit hat man das erste Problem gelöst, aber da hinter jedem kleinen Problem ein grosses Problem steckt, muss auch dieses Problem gelöst werden. Es zeigt sich also, dass die Richtlinien fürs Codemanagement unvollständig sind oder unzureichend umgesetzt werden. In der Regel gilt, nach jeden Bug Fixing, nach jeden Feature oder nach jedem Refactoring sollte das SVN Repository aktualisiert werden. Übrigens kann man auch sehr einfach ein lokales SVN aufsetzen (Setup a Subversion Server in 4 Minutes). Wenn sich dies nur schwierig im eigenen Entwicklungsprozess umsetzen lässt, dann sollte man einen Blick auf Git werfen.

Freitag, 27. August 2010

And the winner is ... ANT

Heute bin ich mit meinem ersten Projekt von Maven zu Ant migriert. Der Aufwand ist überschaubar und das neue Ant-File auch. Das Maven-File umfasste 92 Zeilen wohingegen das Ant-File nur 58 Zeilen umfasste. Eine Ersparnis von  37%, nicht mitgerechnet habe ich da die notwendigen Erweiterungen der Maven Konfigurationsdateien. Leider habe ich noch kein Werkzeug gefunden, dass bei diesen Vorgang unterstützt.
Jetzt funktioniert alles wie gedacht nur das Dependency Management muss ich noch per Ivy ergänzen. Am Besten geht man wie folgt vor:

  1. Sichern des aktuellen Standes des Projekts z.B. im SVN (kurze Anleitung zum Aufsetzen und starten eine SVN Servers unter Linux)
  2. Erzeuge ein neues Verzeichnis im Root-Verzeichnis des Projekts, welches die benötigten Bibliotheken aufnimmt z.B. mkdir lib/
  3. Zeige dir alle von Maven verwalteten Bibliotheken an in dem die pom.xml öffnest.
  4. Kopiere alle direkt abhängigen Bibliotheken aus dem lokalen Maven Repository in das neue Verzeichnis lib, cp /Users/mirkoebert/.m2/repository/commons-io/commons-io/1.4/commons-io-1.4.jar lib/
  5. Ergänze in der build.xml einen Ausdruck der alle JARs im Verzeichnis lib in den Classpath einbindet (siehe Bild oben). 
  6. Deaktivieren des Dependency Managements mit Maven in Eclipse.
  7. Entfernen der Maven Dependencies aus dem Build Path des Projekts und ergänzen der JARs aus dem Verzeichnis lib/.
  8. Löschen der pom.xml aus dem Projektverzeichnis.
  9. Entfernen der Maven-Reste aus den Eclipse-Projektdatei (.project, diese Datei kann man mit dem View Navigator anzeigen und öffnen).
    1. Entfernen Maven-Builders entweder via Menü in den Projekteinstellungen oder man löscht den zweiten buildCommand-Block (siehe Bild unten)
    2. Entfernen der Maven-Natur durch löschen der zweiten nature-Zeile (Bild unten)