Mit ‘grails’ getaggte Artikel

Griffon: Mit einem “Flügelschlag” außer Gefecht gesetzt

Donnerstag, 04. März 2010

Es gibt ein Sprichwort: “Kleinchen heb die Beinchen jetzt kommen Steinchen”. So geschehen bei mir, als ich das erste Mal Griffon unter Windows ausprobieren wollte.

Es ließ sich Partout nicht starten und belegte mich mit der Meldung, dass meine “JAVA_HOME”-Variable auf ein invalides Verzeichnis verweisen würde. Leider konnte ich auf dem System nicht die JAVA_HOME direkt ändern, sondern musste diese in den Umgebungsvariablen des Benutzers “überschreiben”. Ist dann schon etwas unschön, aber gut – es ging erstmal ans Werk.

Nun ist man ja als alteingesessener Java-Entwickler daran gewöhnt, dass Pfade mit Leerzeichen nie gut ankommen. Also 1. Versuch: Leerzeichen entfernen – Kein Erfolg. Einmal ist keinmal, also nächster Versuch: Suchmaschine bemühen – wenig Erfolg.

Die Suche gab zwar nicht die vollständige Antwort, aber zumindest einen Anhaltspunkt. Der abschließende Backslash im Pfad könnte ein Problem sein. Zwar führte dieser Ansatz erstmal zu einem gewissen Erfolg, aber einfach mal eine Systemvariable überschreiben – auch wenn es nicht so große Unterschiede gab – fand ich nicht so “prickelnd”. Darum kam am Ende der Texteditor zum Einsatz, denn mir war aufgefallen, dass Groovy selbst z.B. keine Probleme mit dem Pfad hatte.

Und da war sie – die Lösung, die ich gesucht hatte:

@rem Remove trailing slash from JAVA_HOME if found
if "%JAVA_HOME:~-1%"=="\" SET JAVA_HOME=%JAVA_HOME:~0,-1%

Mit dieser Zeile wird einfach das abschließende Backslash entfernt. Diese Zeile in die startGriffon.bat unter :have_JAVA_HOME geschrieben und plötzlich funktioniert es auch mit dem Greif.

:have_JAVA_HOME
if "%JAVA_HOME:~-1%"=="\" SET JAVA_HOME=%JAVA_HOME:~0,-1%
@rem Validate JAVA_HOME
%COMMAND_COM% /C DIR "%JAVA_HOME%" 2>&1 | %FIND_EXE% /I /C "%JAVA_HOME%" >nul

Leider wurde das Problem auch in der aktuellen Version 0.3 nicht gefixt.

Hudson und Grails am heimischen Herd

Donnerstag, 13. August 2009

Nachdem sich verschiedene Projekte bei mir angesammelt haben und ich für jedes in der Regel ein entsprechendes Trac-Projekt angelegt habe, fehlte mir immer mehr die projektübergreifende Oberfläche.

Mit den Wochen und Monaten schwängerte sich mein Geist mit dem Gedanken sich an Trac “zu vergreifen” und selbst so eine Oberfläche zu schreiben. Zum Glück kam mir eine neue Anforderung in den Weg, die mir die Arbeit teilweise abnahm: der Wunsch eines Continuous Integration Systems – kurz CI.

Da ich schon gute Erfahrungen mit Hudson gemacht hatte, war die Entscheidung schnell getroffen das System auch für mich einzusetzen. Die Vorteile:

  • einfache Installation
  • Open Source
  • kostenfrei

Allerdings musste gewährleistet werden, dass man damit Grails-Projekte bauen kann. Schaut man in die Plugin-Liste schreit es einen förmlich an: “Hier bin ich. Ist total easy-schneasy. Machs einfach!”

Aber wie so oft bei so offensichtlichen Aktionen liegt die Tücke im Detail. Leider hören – wie so oft – die Tutorials im Netz bei der Hälfte auf und vermitteln einem das Gefühl, dass man zu doof für die IT-Welt ist. Deshalb möchte ich hier einfach meine Erfahrungen bei der Einrichtung von Hudson mit den Grails- und Trac-Plugin auf einem Ubuntu-System vorstellen.

System

  • Ubuntu 09.04
  • Tomcat 6 (aus den Ubuntu-Repository)
  • Trac (manuell installiert)
  • Grails 1.1.1

Anmerkung
Ob Trac jetzt manuell oder aus dem Repository installiert wurde, ist eigentlich egal.

Hudson

Als erstes ging es darum Hudson zu installieren. Zwar bietet Ubuntu auch hier an über eine kleine Erweiterung der Repositories Hudson als Daemon zu installieren, allerdings bin ich persönlich kein großer Freund davon. Deshalb Alternative: war-File downloaden und einfach im Tomcat deployen.

Achtung!!! Wenn man das macht, sollte man vorsichtig beim Neustart aus Hudson heraus sein. Die Applikation fährt interessanterweise den Tomcat runter, bekommt ihn aber danach nicht mehr gestartet.

Zwei Dinge muss man dabei beachten, die aber auch auf der Hudson-Seite dokumentiert sind.

  1. die Variable HUDSON_HOME muss gesetzt sein – habe ich bei mir direkt in das Tomcat-Startskript geschrieben (Faulheit siegt)
  2. Es müssen teilweise noch Verzeichnis-Rechte angepasst werden, damit Hudson korrekt läuft

Nachdem Hudson nun endlich sein Pracht im Browser präsentiert geht es weiter mit dem Grails-Plugin.

Grails

Die Installation von Plugins ist in Hudson sehr simpel – oder wie manch Web 2.0-Entwickler sagen würde: “kissy” (von KISS – Keep it stupid simple). Einfach Häkchen setzen und auf “Installieren” klicken. Wie schon erwähnt, kann es hierbei dazu kommen, dass Hudson den kompletten Tomcat versucht neu zu starten, was zumindest bei mir nicht funktioniert hat. Ggf. einfach den Tomcat manuell neu starten.

Nachdem das Plugin installiert ist, müssen noch einige Konfigurationen durchgeführt werden. Als erstes muss der “Grails Builder” in der globalen Konfiguration von Hudson angelegt werden. Hier kann man verschiedene Grails-Installationen angeben, was insbesondere durch die teilweise Inkompatibilität der Versionen von großem Vorteil ist. Da die Sache in zwei Textboxen geregelt wird, verzichte ich mal auf den obligatorischen Screenshot.
Hat man jetzt die notwendigen Installationen angegeben kann man sich gütlich an die Konfiguration des Jobs machen. Hier muss ich vorausschicken, dass ich bereits einige Jobs angelegt hatte.

Unter dem Punkt “Build Verfahren” kann man über den Button “Build-Schritt hinzufügen” ein “Build with Grails” anlegen. Dabei lassen sich verschieden Werte konfigurieren. Nach einigem Herumprobieren waren aber nur drei relevant:

  1. Grails Installation (wurde eben in der globalen Konfiguration angelegt)
  2. Targets
  3. grails.work.dir

Die Targets kann sich jeder selbst aussuchen aus der Liste, die “grails help” ausgibt. Bei mir sind das "test-app -unit --non-interactive" war doc.
Wichtig ist allerdings vor allem der Parameter grails.work.dir!

Das Grails-Plugin erwartet standardmäßig, dass es Zugriff auf das Verzeichnis /usr/share/tomcat6/.grails besitzt um auf den scriptCache zugreifen zu können. Da dieses Verzeichnis aber nicht zwingend freigegeben werden soll, muss ein alternatives Verzeichnis über grails.work.dir gesetzt werden. Andernfalls müssen die Zugriffsrechte mittels sudo chmod -R 777 /usr/share/tomcat6/.grails gesetzt werden.
Das Projekt-Verzeichnis hat noch eine weitere Bedeutung. Wenn man z.B. in Subversion seinen Code unter “trunk” eincheckt und keinen expliziten Modulpfad angelegt hat, wird automatisch trunk als Projektname auch in Hudson beim Bauen verwendet. Nun kann man sich vorstellen, dass bei mehreren Projekten, die alle in “trunk” liegen dies zu einer Überschneidung führt, die nicht unbedingt erwünscht ist.

Nichtsdestotrotz, bin ich hiermit bereits an das Ende meiner Vorstellung gekommen. Nach der Konfiguration des Jobs einfach auf “Jetzt bauen” klicken und schauen was passiert – ich hoffe mal es funktioniert. Ansonsten: bitte nicht hauen, bei mir läufts ;)

Trac

Für alle, die jetzt fragend dastehen und wissen wollen: “aber er hat doch was von Trac erzählt”. Ja, das habe ich und ja, auch das geht sehr einfach. Nachdem man das Trac-Plugin installiert hat, erscheint ein Eingabefeld in der Job-Konfiguration, in dem man einen Link zum Trac-Projekt hinterlegen. Nachdem man diesen gespeichert hat, erscheint ein simpler Menüpunkt auf der Job-Seite “Trac”, der zu der entsprechenden Trac-Seite führt.

Notelib 0.2.5 release + PINCServices.de revised

Sonntag, 15. Februar 2009

Zwei Neuerungen stehen heute ins Haus. Einerseits der Release von PINC-Notelib und andererseits die Überarbeitung der PINCServices.de-Homepage. Auch wenn extern mehr der Blog referenziert wird, gibt es auch eine klassische Einstiegsseite.

Notelib Release

Es ist soweit, die neue Version von PINC-Notelib ist online. Unter PINC-Apps finden sich die Downloadlinks für die Binär- und die Sourcecodeversion. Außerdem gibt die Featureliste einen groben Überblick über die enthaltenen Funktionen, die die Applikation bereithält.
Ich will darauf hinweisen, dass es sich dabei um eine Webapplikation handelt und einen Servletcontainer (z.B. Tomcat) zum laufen benötigt.

PINCservices.de in “neuem” Gewand

Nach einiger Überlegung habe ich mich dazu entschieden die Ausrichtung von PINCServices zu ändern. Es wird von einem reinen Auftragsgeschäft zurücktreten und sich auf die Erstellung von Webapplikationen auf Grails- und Java-Basis konzentrieren.

Mit den inhaltlichen Änderungen kommen auch ein paar technische Neuerungen einher. So wurde der Unterbau der Homepage von pincservices.de ein wenig aufpoliert. Mit Savant3 (http://www.phpsavant.com) steht dafür eine sehr angenehme Templating-Engine zur Verfügung.

Referenzprojekt Grails-Forum

Donnerstag, 06. März 2008

Nachdem ich einige Zeit nichts von mir hören lassen habe, gibt es dafür gleich mehrere Neuigkeiten. Eine davon ist ein Referenzprojekt, an dem ich aktuell mitwirke.
Über Grails wird in letzter Zeit immer mehr geredet, aber scheinbar gibt es kaum bzw. keine Referenzprojekte bzw. Produkte, die die Effektivität und den Funktionsumfang von Grails überzeugend darstellen. Aus diesem Grund hat sich eine kleine Gruppe von Grails-Usern dazu entschlossen ein Forum auf Basis von Grails zu entwickeln. Unter der URL http://code.google.com/p/groowe/ befindet sich die aktuelle Projektseite.