Für mich war schon die neue interaktive Grails Console mit TAB- Vervollständigung, farbiger, einzeiliger Ausgabe und formatierten Fehlerausgaben das Upgrade wert. Sie ist vor allem bei der Befehlsausführung sehr viel schneller, da dafür keine eigene JVM gestartet werden muss.
Als Testkandidat musste meine Beispiel Grails Anwendung grum (sourcecode auf Google Code) herhalten. Doch so einfach wie ein upgrade von einer Minor Version auf eine andere war es nicht.

Als erstes sollte man die upgrade Hinweise verinnerlichen, denn ein einfaches grails upgrade führte bei mir erst einmal zu einem inkonsistentem Projekt in meiner Entwicklungsumgebung (SpringSource Tool Suite).

Schuld ist man meistens selbst. Doch wo liegen nun die Fallstricke?

Dependency Management

Ein Thema, was ich bis jetzt vollständig ignoriert hatte, war das Dependency Management. In den vorherigen Grails Versionen lagen alle benötigten Bibliotheken (wie der JDBC Treiber) im lib Verzeichnis. Sauberer ist es natürlich die Abhängigkeiten zu deklarieren. Bei Grails macht man dies in der BuildConfig Klasse.

conf/BuildConfig.groovy

dependencies {
   // specify dependencies here under either 
   //'build', 'compile', 'runtime', 'test' or 'provided' scopes eg.
 
   runtime 'mysql:mysql-connector-java:5.1.16'
   build "displaytag:displaytag:1.2"
   runtime "displaytag:displaytag-export-poi:1.2"
   runtime "displaytag:itext:1.3"
   runtime "displaytag:poi:3.2"
}

Danach sollte man in der IDE die Abhängigkeiten über Grails Tools -> Refresh Dependencies aktualisieren. Reicht dies nicht aus (wie bei mir) hilft es das Dependency Management zu stoppen und zu starten.

• Grails Tools -> Disable Dependency Management
• Grails Tools -> Enable Dependency Management

Alternativ kann man in der Grails Konsole folgende Befehle absetzen:

grails> clean
grails> war

Plugins

Dabei kam es bei mir zu Kompilierungs Problemen im Zusammenhang mit den automatisch installierten Plugins jquery und resources, was ich nur durch eine Neuinstallation der Plugins beheben konnte

grails> uninstall-plugin <plugin-name>
grails> install-plugin <plugin-name>

TagLibs

Und wo man schon mal beim Aufräumen ist. Das Tag createLinkTo ist depracted und sollte durch das Tag resources ersetzt werden. An dieser Stelle sollte man auch auf folgenden upgrade Hinweis achten:

If you install Resources (or it is installed automatically), tags like <g:javascript> won’t write anything to the page until you add the <r:layoutResources/> tags to your layout.

Content Negotiation

Ein Punkt warum ich Grails so mag ist, das sich damit sehr leicht REST APIs umsetzen lassen. Hier hat sich in der Version 2.0 auch etwas geändert. Die Content Negotiation richtet sich jetzt nicht mehr nach dem akzeptierten Format des Responses, sondern nach dem Content-Type des Requests.
Dafür muss man im Code withFormat durch request.withFormat ersetzen. Testen kann man diese Änderung mit curl. Z.B. mit:

curl --header Content-Type:text/xml http://localhost:8080/grum/contactData/list

Fazit:
Das Upgrade lohnt sich, auch wenn es mit etwas mehr Arbeit verbunden ist, als sonst.

Links:
grum – Grails 2.0 Beispiel Applikation

via:
Neues Video-Tutorial zu Grails – it-republik.de

Dies ist ein paar Monate her und die Unterstützung der Erstellung von Grails Anwendungen durch Eclipse ist stetig besser geworden.
War es zum Anfang so, dass die mit Abstand beste IDE für Grails IDEA war, so holt das freie Eclipse immer mehr auf. Spätestens mit dem Wechsel der Grails Entwickler zu Springsource und der damit verbundenen Einbettung in die Eclipse basierte Springsource Tool Suite (STS) hat sich eine Menge getan.

Mal abgesehen von dem Hauptspeicher – Hunger von STS fühle ich mich als alter Eclipse Nutzer gut aufgehoben. Mit Netbeans und IDEA konnte ich mich nie so richtig anfreunden.

Um den Grails Support zu aktivieren müssen die Grails und Groovy Extensions über den Reiter Extensions des STS Dashboards installiert werden (s. Screenshot). Danach gibt es für Grails Projekte eine eigene Perspektive mit Syntax Highlighting, Code Vervollständigung und einer übersichtlichen Navigation im Project Explorer.
In der Toolbar gibt es in der Grails Perspektive einen Button zur Ausführung von Grails Befehlen (wie z.B. run-app).

Bei der Installation der Grails Extensions wird im Installationsverzeichnis des STS die aktuelle Grails Version abgelegt.

~ > ls springsource/
   grails-1.3.5
   grails-1.3.6				
   grails-1.3.7
   maven-2.2.1.RELEASE				
   roo-1.1.0.RELEASE			
   tc-server-developer-2.0.4.RELEASE
   sts-2.5.0.RELEASE

Gibt es bei den Updates (Help -> check for Updates) eine neue Grails Version wird diese dort hinzugefügt. In den Preferences (Groovy -> Grails) muss man dann die neue Version für den Workspace übernehmen. Im Grails Projekt ist dann noch der upgrade Befehl notwendig.

Fazit:
Die Grails Integration in Eclipse hat einen großen Schritt nach vorn getan. Vom Funktionsumfang dürfte IDEA immer noch führen. Grails Projekte werden dort allerdings nur in der kostenpflichtigen ULTIMATE Variante unterstützt.
Die kostenfreien Entwicklungsumgebungen Netbeans und die Eclipse basierte STS unterscheiden sich kaum in der Grails Unterstützung. Hier entscheidet die persönliche Vorliebe über die IDE.

Links:
Diskussion zu diesem Thema auf stackoverflow.com

Ich habe bei der Umsetzung bewusst auf die vielen Grails Plugins verzichtet, um so wenig Seiteneffekte wie möglich zu haben und es auch für diejenigen einfach zu halten, die einen Einstieg in Grails suchen. So sind in Grum Lösungen enthalten, wie man z.B.:

• den Zugriff auf eine Mysql Datenbank realisiert
• 1:1, 1:n und n:m GORM Beziehungen modelliert
• eigene Tag Libs schreibt
• die JSP Tag Lib displaytag verwendet, um die Daten seitenweise anzuzeigen, zu gruppieren, zu sortieren und in alle möglichen Formate (excel, csv, xml, pdf) zu exportieren
• den Upload von Dateien ermöglicht
• funktionale Tests mit dem webtest Plugin verwendet
• und die Auslieferung von XML aufgrund von besonderen URL’s (kurz Content Negotiation) umsetzt

Die neue Version 0.3 verwendet jetzt grails 1.2.1 und das Plugin webtest in der Version 2.0.3. Die Sourcen, die SQL Dateien zur Erstellung der Mysql Datenbank und ein Webarchiv mit allen notwendigen Bibliotheken stehen auf Google Code zum Download bereit.

Nutztungshinweise:
Der Code kann frei verwendet werden, kann aber Fehler enthalten, für die ich keine Haftung übernehme. Die Lizenzbedingungen der verwendeten Bibliotheken sind einzuhalten.

Displaytag ermöglicht es ohne große Klimmzüge Tabellen in Java Server Pages auf mehrere Seiten aufzuteilen (Paging), zu sortieren, zu gruppieren und nach Excel, Csv, Xml und Pdf zu exportieren.
Grails unterstützt “out of the box” nur das Paging und lange Zeit konnte man keine JSP Tag Libs in Grails verwenden, so dass man die restlichen Funktionalitäten entweder durch Plugins abbilden konnte oder selbst Hand anlegen musste.

Seit Grails 1.1 ist diese Beschränkung nun aufgehoben und der Test die beiden zu vereinen ist schon seit längerem erfolgreich abgeschlossen. Nur der Blog Eintrag darüber steht seit dem noch auf meiner ToDo Liste. Aber was lange währt wird gut (hoffe ich ).

Folgende Schritte sind zur Integration von displaytag in Grails notwendig:

libs

Zuerst sollten die Displaytag Bibliotheken neben dem Datenbank Treiber ins lib Verzeichnis kopiert werden.

Displaytag Konfigurationsdatei

Die Konfigurationsdatei von displaytag displaytag.properties muss unter src/java erstellt werden. Der Aufbau dieser Datei ist in der Doku von displaytag beschrieben. Für mein grum Projekt sieht die Konfiguration so aus:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

export.types=csv excel xml pdf
export.excel=true
export.csv=true
export.xml=true
export.pdf=true
export.excel.class=org.displaytag.export.excel.DefaultHssfExportView
export.pdf.class=org.displaytag.export.DefaultPdfExportView
export.rtf.class=org.displaytag.export.DefaultRtfExportView
export.banner=<div class="exportlinks">Export to: {0}</div>
export.amount=list
paging.banner.placement=bottom
basic.msg.empty_list=No data found.
basic.msg.empty_list_row=<tr class="empty"><td colspan="0">No data found.</td></tr></tr>
paging.banner.full=<span class="pagelinks"><a href="{1}"><strong>&lt;&lt;</strong></a>&nbsp;&nbsp;&nbsp;<a href="{2}"><strong>&lt;</strong></a>&nbsp; {0} &nbsp;<a href="{3}"><strong>&gt;</strong></a>&nbsp;&nbsp;&nbsp;<a href="{4}"><strong>&gt;&gt;</strong></a></span>
paging.banner.first=<span class="pagelinks"> {0} &nbsp;<a href="{3}"><strong>&gt;</strong></a>&nbsp;&nbsp;&nbsp;<a href="{4}"><strong>&gt;&gt;</strong></a></span>
paging.banner.last=<span class="pagelinks"><a href="{1}"><strong>&lt;&lt;</strong></a>&nbsp;&nbsp;&nbsp;<a href="{2}"><strong>&lt;</strong></a>&nbsp; {0} </span>
paging.banner.one_item_found=<span class="pagebanner">1 Record found. Seite: </span>
paging.banner.all_items_found=<span class="pagebanner"> {0} Records found. Seite: </span>
paging.banner.some_items_found=<span class="pagebanner"> {0} Records found, show {2} - {3}. </span><br /><br />

Displaytag Wrapper

Dynamische Links und Formatierungen werden in displaytag über das Decorator Pattern umgesetzt. Der Decorator wird in einer Wrapper Klasse implementiert, die in Grails natürlich in Groovy geschrieben ist. Meine Implementierung ist die Klasse DisplaytagWrapper, die im grum Projekt einen Link zu den Details der Benutzer erstellt und das Erstellungsdatum formatiert.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

package de.koo.grum.groovy.util
 
import org.displaytag.decorator.TableDecorator;
 
public class DisplaytagWrapper extends TableDecorator{
   String getLinkToUser() {
      def user = getCurrentRowObject()
      return "<a href=\"/grum/user/show/${user.id}\">${user.username}</a>";
   }
   String getUserCreatedAt() {
      def user = getCurrentRowObject()
      return user.createdAt.format("dd.MM.yyyy HH:mm");
   }
}

Export Filter

Beim Export in ein nicht HTML Format muss der content type für die Antwort an den Browser neu gesetzt werden. Damit dies nicht zu Problemen führt, sollte ein Filter in der web.xml Datei definiert werden, der möglichen Fehlern entgegenwirkt. Displaytag bringt mit der Klasse ResponseOverrideFilter bereits eine Implementierung dafür mit.

Um in Grails Änderungen an der web.xml vornehmen zu können, müssen die Templates installiert werden:

grails install-templates

Danach befindet sich die web.xml im Verzeichnis src/templates/war. Für den Filter sind folgende Einträge notwendig.

1
2
3
4
5
6
7
8

<filter>
   <filter-name>ResponseOverrideFilter</filter-name>
   <filter-class>org.displaytag.filter.ResponseOverrideFilter</filter-class>
</filter>
<filter-mapping>
   <filter-name>ResponseOverrideFilter</filter-name>
   <url-pattern>/*</url-pattern>
</filter-mapping>

Einbindung in Groovy Server Page

Hat man diese ganzen vorbereitenden Schritte absolviert, kann man sich endlich an die Verwendung von displaytag in einer Groovy Server Page machen.
In meinem Beispiel user/list.gsp werden alle Benutzerdaten tabellarisch angezeigt. Die Tabelle ist durch das Attribut sortable nach Vor- und Nachnamen sortierbar (ohne erneuten Datenbankzugriff) und wird beim Erreichen der pagesize über das Attribut partialList auf mehrere Seiten verteilt.

1
2
3
4
5
6
7
8
9
10
11
12
13

<%@ taglib uri="http://displaytag.sf.net" prefix="display" %>  
<html>
..
<display:table name="userList" defaultsort="1" partialList="true" 
      decorator="de.koo.grum.groovy.util.DisplaytagWrapper"
      size="${resultSize}" pagesize="${pageSize}" requestURI="/grum/user/list"
      class="listing" cellpadding="0" cellspacing="0" sort="list">
   <display:column property="linkToUser" title="Userame" />						
   <display:column property="firstname" title="Firstame" sortable="true"/>						
   <display:column property="lastname" title="Lastname" sortable="true"/>						
   <display:column property="userCreatedAt" title="Created At" sortable="true"/>						
</display:table>
...

Über zusätzliche Attribute (export, group) kann wie im Beispiel contactData/list.gsp auch der Export in die verschiedenen Ausgabeformate und eine Gruppierung der Einträge erreicht werden.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<display:table name="contactDataList" export="true" defaultsort="1" partialList="true" 
      decorator="de.koo.grum.groovy.util.DisplaytagWrapper"
      size="${resultSize}" pagesize="${pageSize}" requestURI="/grum/contactData/list"
      class="listing" cellpadding="0" cellspacing="0" sort="list">
    <display:setProperty name="export.csv.filename" value="contactData.csv" />
    <display:setProperty name="export.excel.filename" value="contactData.xls" />
    <display:setProperty name="export.xml.filename" value="contactData.xml" />
    <display:setProperty name="export.pdf.filename" value="contactData.pdf" />
    <display:setProperty name="export.amount" value="list" />
 
    <display:column property="linkContactDataToUser" title="Name" sortable="true" group="1"/>						
    <display:column property="type" title="type" sortable="true" />
    <display:column property="data" sortable="true" />
</display:table>

Fazit:
Einmal konfiguriert ist displaytag eine der tollsten Lösungen für java basierte Webanwendungen um Daten tabellarisch aufzulisten. Der Funktionsumfang übertrifft dabei weit die Standard Funktionalität von Grails. Die Kombination von Grails und displaytag kann ich daher nur jedem empfehlen.

Links:
grum Quellcode

Still und leise ist sie dahergekommen. Wie viele andere Groovy Projekte (Groovy 1.7, GPars 0.9, Gant 1.9) ist auch für Grails pünktlich zur Groovy&Grails Exchange eine neue Version erschienen. Die finale Version 1.2 hat lange auf sich warten lassen.

Eine stabile Version sollte es werden. Das war der Grund für die lange Beta und RC Phase. So basiert Groovy 1.2 auch noch auf der Groovy Version 1.6.7.

Zur neuen Version hat Dierk König (Author von Groovy in Action) einen ausführlichen Artikel geschrieben, so dass an dieser Stelle nur eine kurze Liste neuer Funktionen folgt:

• Deklarative Abhängigkeiten für Bibliotheken innerhalb von Grails Anwendungen
• Schnellere Sichten – Performancesteigerungen für Groovy Server Pages (GSP)
• GORM defaults werden konfigurierbar
• Named queries, die auch als Selektionsbasis für die dynamischen Finder Methoden dienen können
• Ausbau, der eh schon sehr guten REST und JSON Unterstützung
• die Grails documentation engine kann auch für andere (nicht auf Grails basierende) Anwendungen genutzt werden
• Update auf Spring 3
• fein granular konfigurierbare DataSources
• erweiterte Unterstützung von annotierten Entities
• Tomcat als Default Servlet Container. Andere Servlet Container wie z.B. Jetty werden ebenfalls unterstützt.

Die komplette Liste der Änderungen könnt Ihr im Change Log und den Release Notes nachlesen.

Grails 1.2 steht auf der Projektseite zum Download bereit. Für bestehende Grails Anwendungen reicht wie immer ein

grails upgrade

Der Sprung von Version 1.1 auf 1.2 ist nicht so groß, wie der von Version 1.0 auf 1.1. Von daher sind bis jetzt nur wenige Probleme bekannt.

Das auf Groovy basierende Webframework Grails ermöglicht in der Java Welt eine schnelle Entwicklung von Webapplikationen. Die Schnelligkeit erkauft man sich aber nicht durch den Verzicht auf Tests. Im Gegenteil.

Mit dem Canoo – Webtest Plugin sind die Tests genauso schnell geschrieben, wie die Anwendung selbst (was aus meiner Sicht der einzige Weg ist dem Entwickler das Testen schmackhaft zu machen).

Für die Installation reicht ein simples:

> grails install-plugin webtest

Und mit:

1
2
3
4
5
6

> grails create-webtest
WebTest name not specified. Please enter:
<domain-name>
     [copy] Copying 1 file to <Pfad zur Grails App>
     [copy] Copying 1 file to <Pfad zur Grails App>/webtest/tests
Web Test generated at webtest/tests/<domain-name>Test.groovy

erstellt man seinen ersten Test für eine Domainklasse von Grails. Alle Tests werden standardmäßig unter /webtest/tests abgelegt. Ein generierter Test könnte so aussehen:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

class GroupTest extends grails.util.WebTest {
 
    def testGroupListNewDelete() {
	invoke      'group'
	verifyText  'Home'
 
	verifyListSize 0
 
	clickLink   'New Group'
	verifyText  'Create Group'
	clickButton 'Create'
	verifyText  'Show Group', description:'Detail page'
	clickLink   'List', description:'Back to list view'
 
	verifyListSize 1
 
	group(description:'edit the one element') {
	    showFirstElementDetails()
	    clickButton 'Edit'
	    verifyText  'Edit Group'
	    clickButton 'Update'
	    verifyText  'Show Group'
	    clickLink   'List', description:'Back to list view'
	}
 
	verifyListSize 1
 
	group(description:'delete the only element') {
	    showFirstElementDetails()
	    clickButton 'Delete'
	    verifyXPath xpath:  "//div[@class='message']",
			text:   /.*Group.*deleted.*/,
			regex:  true
	}
 
	verifyListSize 0
    }
 
    String ROW_COUNT_XPATH = "count(//div[@class='list']//tbody/tr)"
 
    def verifyListSize(int size) {
        ant.group(description:"verify Group list view with $size row(s)") {
            verifyText  'Group List'
            verifyXPath xpath:      ROW_COUNT_XPATH,
                        text:       size,
                        description:"$size row(s) of data expected"
        }
    }
 
    def showFirstElementDetails() {
        clickLink   '1', description:'go to detail view'
    }
}

und sollte natürlich auf die eigene Anwendung vor dem ersten Testlauf angepasst werden. Tests startet man entweder für eine TestSuite, einen TestCase oder einer Methode aus einem TestCase.

# TestSuite
> grails run-webtest
 
# TestCase
> grails run-webtest <webtest>
 
# Methode aus einem TestCase
> grails run-webtest <webtest> <test pattern>

Für den Test wird versucht den ServletContainer zu starten. Bei laufender Grails Applikation empfiehlt es sich daher mit der Option -nostart zu arbeiten. Das Ergebnis wird detailliert in einer HTML Seite dargestellt, die nach dem Test sofort im Browser aufgerufen wird.

Gerade das Testen von Formularen ist ziemlich stupide. Canoo Webtest bringt für diese Aufgabe einen Webrecorder mit. Dabei handelt es sich um ein Firefox Plugin, mit dem die Bedienung der Webanwendung aufgezeichnet werden kann. Die einzelnen Testbefehle werden im Groovy, XML und Webdriver Formatabgespeichert. Zusätzlich können XPath Abfragen getestet werden.

Fazit:
Testen muss nicht langweilig und stupide sein. Das Canoo Webtest Plugin für Grails ermöglicht das schnelle Erstellen von Tests, was zu einer höheren Testabdeckung der eigenen Webanwendung führt.
Canoo Webtest lässt sich aber auch für Webanwendungen nutzen, die nicht auf Grails basieren. So könnte man es auch PHP oder Ruby Webanwendungen damit testen. Da Canoo Webtest auf dem Build Tool Ant basiert, ist es sehr einfach es in den Build Prozess einzubinden. Die Ergbenisse können dann auch im Continuous Integration Server Hudson angezeigt werden. Dies stellt sicher, dass die Tests dann auch zyklisch ausgeführt werden.

Somit kann eigentlich nichts mehr schief gehen.

Links:
Canoo Webtest Plugin
Firefox Plugin – Webtest Recorder
Testautomatisierung mit WebTest
Hudson Plugin

Update:
Mit Grails 1.2 wird Webtest nicht mehr im Bundle mit ausgeliefert. Von daher steht erst einmal ein Download des Plugins an, dass dann auch gleich in der Version 2 daherkommt und zahlreiche Änderungen mit sich bringt.
Unter anderem wechselt der Ort für das webtest Verzeichnis. Es liegt jetzt unterhalb des Test Verzeichnisses. Alte Tests bedürfen auch einer Änderung bevor sie wieder laufen. Die Testmethoden müssen jetzt mit void und nicht mehr mit def angelegt werden.

Gestartet werden die Tests jetzt mit:

> grails test-app -functional

Weitere Änderungen kann man unter diesem Link oder auf der Seite des Plugins nachlesen.

Eine der wichtigsten Resourcen, wenn man sich mit Groovy und Grails beschäftigt, ist aus meiner Sicht der Grails Podcast von und mit Sven Haiges und Glen Smith.

Der Podcast, der alle 2 Wochen in englischer Sprache erscheint, hat nun die Folge 100 erreicht.
Alles Gute von meiner Seite zu diesem Ereignis und vielen Dank für die zahlreichen Informationen und News der letzten Jahre rund um die Themen Groovy und Grails.

Macht weiter so.

Aus meiner Sicht ist Groovy, die dynamische Sprache für die Java Virtual Machine, auf der großen Hype Kurve am Punkt der technischen Realität angekommen. Mit Scala und Clojure werden statt dessen gerade 2 neue Programmiersprachen durch die Gemeinde der Java Jünger getrieben.

So ist es an der Zeit einmal zu hinterfragen, was man selbst bis jetzt mit Groovy implementiert hat, ob man dabei bleibt oder doch auf den Scala Zug aufspringt.

Dierk König, der Autor von “Groovy in Action” (dem besten Fachbuch, das ich in letzter Zeit gelesen habe), hat einmal folgende 7 Anwendungsmuster für Groovy herausgearbeitet:

Super Glue, Liquid Heart, Keyhole Surgery, Smart Configuration, Unlimited Openness, House-Elf Scripts, Prototype

Oder nicht ganz so prosaisch, als:

• Bindeglied zwischen Java Komponenten (wie z.B. Spring und Hibernate in Grails)
• Auslagerung der Buisiness Logik, um sie dynamisch auf Veränderungen anpassen zu können
• Eingriffsmöglichkeit in laufende Applikationen
• Erweiterung der Konfiguration mit den Mitteln einer Programmiersprache (um endlich das plumpe XML loszuwerden)
• die leichte Veränderung von Code zur Laufzeit
• Hilfe für alle Aufgaben, die durch die Programmierung anfallen (Build automation, continuous integration, deployment, installer, service monitoring, reports, statistics, automated documentation, functional tests, HTML scraping, Web remote control, XML-RPC, WebServices)
• Tool zur schnellen Erstellung von Prototypen, mit der Möglichkeit diese später auf Java portieren zu können.

Doch zurück zum Ausgangspunkt. Was mache ich mit Groovy?

Zuerst einmal schreibe ich 95 % aller neuen Tests in Groovy. Die knackige Syntax, die perfekte Interoperabilität mit Java und die gute (aber verbesserungsfähige) Integration in Eclipse machen die Erstellung von Tests sehr viel weniger lästig. Zudem gibt es kleinere Web- und Webservices Applikationen auf Basis von Grails (dem Webframwork, das seinerseits ebenfalls auf Groovy basiert), sowie Tools, die rein in Groovy geschrieben sind.

Letztendlich kann man sagen, der Hype ist dem Alltag gewichen und Groovy passt sich perfekt in die tägliche Arbeit ein. Mit Griffon und GPars stehen 2 weitere Frameworks für Swing Applikationen und Nebenläufige Programmierung (Threads) auf Groovy Basis zur Verfügung. Und eine lebendige Community hat sich um diese dynamische Sprache gebildet. Ein Umstieg auf Scala oder Closure kommt somit für mich momentan nicht in Betracht.

Und mal ganz ehlich, wenn die Kinder fragen: “Papa was machst Du?”, klingt “ich programmiere Groovy” viel cooler als “Ich programmiere Scala”.

Links:
Groovy Usage Patterns by Dierk König

Das erste, was man nach dem Urlaub (ohne Internet) macht, ist seine Mails zu lesen. Darunter war eine von Morph AppSpace, von denen ich in einem früheren Beitrag noch über die kostenlosen Developer Accounts für Grails Applikationen berichtet habe. Doch was musste ich da jetzt lesen:

As part of our efforts to focus on providing quality next-generation products and following our previous announcement, effective Monday, July 13, 2009, we are discontinuing FREE AppSpaces for customers without paid AppSpaces.

Also erst zahlen dann kann man weiter kostenlos Entwicklungsstände deployen.

So wird auch meine kleine Applikation Grum nicht mehr bei Morph AppSpace gehostet. Ich werde mir mal die Google App Engine anschauen. Dafür dürften aber ein paar kleine Änderungen notwendig sein (z.B. JPA statt Hibernate für die Persistenz).
Wenn es soweit ist, werde ich meine Erfahrungen natürlich hier im Blog schildern.

Ich will wieder zurück in den Urlaub.