Dienstag, Dezember 30, 2008

Ubuntu für No-Details-Charaktere: Schritt 5 (Entwicklung)

mor.ph ruft. Dort habe ich Clipboard2Web in einem kostenlosen Paket gehostet. Als Gegenleistung verlangt der Hoster, dass ich meine Anwendung mind. monatlich aktualisiere. Ansonsten wird die Anwendung stillgelegt.
Wenn noch 14 Tage übrig sind, bekommt man eine E-Mail, dass man seine Anwendung mal wieder neu deployen sollte. Jetzt ist es soweit.

Downloads
Dazu muss ich Java und Grails unter Ubuntu installieren. Java lässt sich über die in Ubuntu eingebauten Nachlade-Mechanismen elegant und einfach installieren. Ich muss mir nicht mal Gedanken darüber machen, wohin das Zeug installiert werden soll. Ubuntu kennt den jeweils passenden Ort.

Grails muss ich manuell herunterladen. Glückerlicherweise kann ich das direkt als Debian-Package tun und mit dem Package-Installer auch auf Knopfdruck installieren.

JAVA_HOME
Java ist danach auch sofort einsatzfähig, bei Grails muss ich noch selbst Hand anlegen. Grails beschwert sich nämlich darüber, dass JAVA_HOME nicht gesetzt ist. Das macht der Java-Installer offensichtlich nicht selbst. Ist auch klar, weil es sehr viele Möglichkeiten gibt, wo man JAVA_HOME definieren kann. Ich bin da auch kein Experte und definiere es erstmal in /etc/environment. Das scheint das passende Ort für globales Zeug zu sein.

Grails
Danach lässt sich Grails aus der Kommandozeuge starten. Wenn ich allerdings etwas Produktives mit Grails machen will, funktioniert es nicht. Genaueres Hinsehen verrät, dass Grails als Versionsnummer null angibt. Das ist natürlich nicht OK. Kurze Recherche im Internet ergibt, dass das von mir verwendete Debian-Package korrupt ist. Es ist eine korrigierte Version hier, die aus mir unerfindlichen Gründen nicht über die Grails-Download-Page erreichbar ist.

grails upgrade
Allerdinge habe ich die Version 1.0.4 installiert und meine Anwendung habe ich mit Versionb 1.0.3, gebaut. Also beschwert Grails sich, dass die Versionen nicht zusammenpassen. Aber mit grails upgrade ist das Problem schnell behoben. Schnell noch bestätigen, dass Grails einige Dateien ersetzen darf - business as usual. Denkste! Grails hat mein build.xml überschrieben mit der völlig sinnfreien Vorlage. Argh! Naja, nicht so wild. Mein Original-Build-File habe ich ja in meinem Subversion-Repository. Also muss ich noch schnell meinen Lieblings-Subversion-Client installieren: Eclipse.

Eclipse und dann nochmal
Ecllipse kann ich über die Download-Features von Ubuntu elegant installieren. Als ich auf mein SVN-Repository zugreifen möchte, stelle ich fest, dass von Eclipse leider nicht die aktuellste Version installiert wurde. Also lade ich die manuell von eclipse.org herunter. Durch die vorherige automatischen Installation weiß ich jetzt immerhin, wohin ich Eclipse installieren sollte. Also lösche ich die alte Installation von Hand (rm -r), wechsle ins neue Eclipse-Verzeichnis und starte eclipse. Und belohnt werde ich mit einer Fehlermeldung, dass die Installation nicht korrekt ist. Die jetzt folgende Odysee durch das Internet erspare ich dem Leser lieber. Das Ergebnis wird dadurch nicht weniger peinlich für mich. Die Original-Eclipse-Installation hat in einem bin-Verzeichnis ein Shell-Script namens eclipse angelegt und das aktuelle Verzeichnis befindet sich unter Linux per Default nicht im Path. Also habe ich weiterhin das alte Shell-Skript aufgerufen. Nach Löschen des Shell-Skripts und Aufruf durch ./eclipse startet Eclipse schließlich.

Java-VM
Beim Start-Bildschirm warnt Eclipse mich, dass GCJ als Java-VM konfiguriert ist und Eclipse auf dieser VM nicht getestet wurde. Keine Ahnung, was GCJ ist, aber es wird schon klappen. Leider nicht sehr weit. Sobald ich versuche, das Update-Center in Eclipse zu öffnen, schmiert Eclipse ohne weiteres Feedback ab. java in der Shell zeigt, dass GCJ ein bei Ubuntu mitgeliefertes GNU-Java ist. Ich hatte Java 6 von SUN ja bereits installiert. Also schnell noch das passende bin-Verzeichnis in etc/environment zum PATH hinzugefügt und schon läuft auch das Update-Center wieder.

Subversive
Beim Versuch, Subversive als Subversion-Client in Eclipse zu installieren, fällt mir wieder ein, dass Eclipse mein Lieblings-CVS-Client ist. Daraus gleich zu folgern, dass es auch mein Lieblings-SVN-Client ist, war vielleicht etwas voreilig. Jetzt fällt mir wieder ein, wie grauenvoll die Installation von Subversive ist. Ich gehe auf die Installation-Webseite zu dem Subversive-Plugin. Dort steht Schritt für Schritt, was man tun muss. Leider sehr umständlich. So steht dort z.B. nicht, wie due URL für die Update-Site steht. Stattdessen steht dort die URL eine Webseite, auf der die URL für die Update-Site steht. Also muss man erst auf diese Seite und die URL dort suchen. Umständlich. Und wenn man dann das Plugin installiert hat, läuft es nicht, weil andere Plugins fehlen (Connectors, Integrators, ???). Und die finden sich nochmal auf einer anderen Seite. Viel komplizierter geht es wohl nicht. Am Ende bekomme ich das Zeug doch noch zum Laufen - ich habe einfach pauschal alles installiert, was Subversion im Namen hatte (außer das, was explizit Windows im Namen hat). Endlich kann ich mein altes Build-File aus dem Subversion-Repository restaurieren.

Grails in Eclipse
Jetzt öffne ich ein Grails-Projekt, das ich unter Windows erstellt habe. GRAILS_HOME zeigt auf einen Ort auf der Windows-Partition. Das muss ich in Eclipse umbiegen. Kein Problem, vor allem weil Grails so nett ist, mir beim Starten zu sagen, wo es installiert ist - das hat Java nicht von sich aus getan. Das musste ich erst auf der Platte suchen.

Deploy
Und jetzt kann ich aus Eclipse über das Build-File meine Anwendung neu deployen. Hurra, geschafft.

Fazit
Ich war davon ausgegangen, dass ich mit Ubuntu eher im Bereich Multimedia/Office Probleme bekomme als im Bereich Entwicklung. Aber das war weit gefehlt. Die meisten und schwierigsten Probleme hatte ich im Bereich Entwicklung. Aber sie waren auch noch zu meistern.
Ich werde mir aber mal ernsthaft überlegen, ob ich wirklich Subversion verwenden möchte. Gefühlt hatte ich mit CVS weniger Probleme (nicht nur, was den Client angeht). Oder ich gucke mir gleich mal was Innovativeres an, wie z.B. Bazaar.

Post bewerten

6 Kommentare:

Robert Beeger hat gesagt…

Hi Stefan,

Hast du mal Subclipse ( http://subclipse.tigris.org/ ) ausprobiert? Es gibt Leute, die sagen, dass das besser ist als Subversive. Ich habe Subversive nie ausprobiert, kann aber sagen, dass Subclipse ganz gut funktioniert. Es hackt an einigen Stellen, bei denen ich dann auf SmartSVN ( http://www.syntevo.com/smartsvn/index.html ) zurückgreife, aber für die tägliche Arbeit scheint es ganz gut zu taugen.

Viele Grüße,
Robert

Stefan Roock hat gesagt…

Subclipse hatte ich früher mal. Das hatte aber viele, viele Probleme und daher benutze ich seitdem Subversive. Außerdem scheint Subversive von Eclipse.org präferiert und daher dachte ich, ich nehme es.
Falls ich es mal wieder installieren muss, versuche ich es vielleicht vorher mal wieder mit Subclipse.

Sebastian hat gesagt…

Hallo, immer wieder ein Debakel mit Eclipse und SVN, Subclipse oder Subversive... und beides ein wenig hakelig im Alltag. Unter Windows ist TortoiseSVN mein liebster SVN-Client geworden. Vielleicht ist Nautilus ähnlich gut: http://code.google.com/p/nautilussvn/

Du scheinst kein Freund der Kommandozeile zu sein, oder? Es gibt ja noch das eigentliche SVN.

Deine Idee ein verteilte Sourceverwaltung zu benutzen finde ich prima und freue mich auf eine neue Blog-Serie.

Stefan Roock hat gesagt…

zu verteilter Versionsverwaltung (hier: GIT) gibt es einen netten Artikel: http://lbrandy.com/blog/2009/01/the-day-i-got-git-with-some-help-from-github/

Unknown hat gesagt…

Ich benutze Bazaar unter Windows. Bazaar selbst ist sehr unkompliziert. Die Integration mit Eclipse ist aber manchmal hakelig.

traininginstitute hat gesagt…

Your work is very good and I appreciate you and hopping for some more informative posts
data science training