Artikel

 
Januar 2010 | Artikel

Graeme Rocher plaudert über Grails 1.2, die Community und die Roadmap 2010

(Link zum Artikel: http://www.it-republik.de/jaxenter/artikel/2851)

Interview

Text: Marc-Oliver Scheele
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share
Pünktlich zum vergangenen Weihnachtsfest wurde die neue Grails-Version 1.2 veröffentlicht. Vor diesem Hintergrund hat Java-Magazin-Autor und Grails-Experte Marc-Oliver Scheele ein Interview mit Graeme Rocher (Co-Gründer, Projektleiter und Lead-Developer des Grails-Frameworks) geführt.
Teil 1   Teil 2   Teil 3   

Scheele: Graeme, lass uns kurz die Zeit zurückdrehen. Erzähle bitte kurz was Deine Motiviation war das Grails-Framework zu erschaffen? Hattest Du ein konkretes Projekt zu implementieren oder ist es als eine Art persönliches "Forschungsprojekt" entstanden?

Rocher: Ich war CTO in einer Firma, die kundenspezifische Learning-Management (LMS)- und Content-Management(CMS)-Systeme entwickelte. Die Systeme wurden als maßgeschneiderte Lösungen verkauft, die Kosten für die Anpassungen der LMS und CMS schon inklusive. Mit diesen fixen Preisen mussten wir wirklich ultra-produktiv arbeiten, sonst hätten die Kosten für die Anpassungen den Gewinn minimiert.

Die Basis des LMS- und CMS-Systems wurde mit Spring und Hibernate gebaut, und obwohl mir Projekte mit Ruby on Rails und Django gefielen, ließen sich diese so gut wie nie auf die Umgebungen unserer Kunden anwenden. Allerdings hatte ich schon mal Groovy in einem anderen Projekt genutzt, genauer gesagt ging es da um ein Buildsystem für die Erstellung von eLearning-Inhalten aus Word-Dokumenten. Daher wollte ich sehen, ob man mit Groovy eine ähnliche Produktivität erreichen kann.

Wie sich herausstellte, gab es in der Groovy-Mailingliste Bestrebungen, ein Rails-ähnliches Framework zu entwickeln, also half ich dabei, das auf den Weg zu bringen. Daraus entstand Grails. Heute habe ich immer noch Kunden, die CMS-Systeme basierend auf dieser ersten Grails Version 0.1 produktiv einsetzen. Mit der Zeit wurde Grails sehr populär, daher haben wir die Firma G2One gegründet, die später von SpringSource übernommen wurde.

Scheele: Mittlerweile sind vier Jahre vergangen und Grails hat weite Verbreitung gefunden. Der "Unique Selling Point" gegenüber anderen Java-basierten Frameworks ist der sehr geringe Entwicklungsaufwand, um anspruchsvolle Webapplikationen zu implementieren. Welches sind die aus Deiner Sicht beeindruckende Grails-Projekte in Sachen Entwicklungsgeschwindigkeit und Komplexität?

Rocher: Klar! Es gibt viele Projekte da draußen, die Grails nutzen. In Großbritannien hat zum Beispiel der größte Runfunksatellitenanbieter Sky TV sein komplettes Sky.com nach Grails portiert – Sky TV gehört zu News Corporation, denen wiederum Fox in den USA gehört. Das Sky-Team hat ein nicht-triviales maßgeschneidertes CMS-System im Backend implementiert, das Content für über 150 Millionen Aufrufe pro Monat liefert.

Walmarts Gegenstück zum Apple iTunes Store ist ebenfalls in Grails geschrieben und ich glaube, auch hier gibt es erheblichen Traffic. Es gibt noch mehr große Namen wie zum Beispiel LinkedIn und natürlich viele viele Unternehmen, die es intern nutzen, weil es leicht ist, Grails-Applikationen in eine existierende Java-basierte Infrastruktur zu deployen.

Scheele: Gerade ist die Version 1.2 von Grails erschienen. Was ist der Focus dieses Releases ? Welches sind Deine Top-3 Features dieser Version?

Rocher: Der Fokus in diesem Release lag auf Stabilität und Geschwindigkeit. Wir haben die GSP-Rendering-Engine überarbeitet und es ist gut zu sehen, dass Grails seine Position als performantestes Framework einer dynamischen Sprache auf dem Markt stärken konnte. Wir haben auch einige Build-Infrastruktur-Verbesserungen implementiert, zum Beispiel die Möglichkeit, JAR-Abhängigkeiten mit einer Dependency-Resolution-DSL zu spezifizieren, die auf Ivy basiert.

Auch GORM (der ORM-Layer gebaut mit Hibernate) hat Veränderungen erfahren – es gibt eine neue Syntax für dynamische Finder und die Möglichkeit, wieder verwendbare Named-Queries zu spezifizieren, die mit zusätzlichen Merkmalen verbunden werden können. Hierdurch können Queries wesentlich besser das DRY Prinzip unterstützen. Apropos DRY: wir haben ebenfalls globale Constraints und ORM-Mapping-Definitionen hinzugefügt, so dass man nun einfacher das Standardverhalten der GORM-Domain-Klassen global spezifizieren kann. Abgesehen davon gab es Hunderte kleinere Features und Verbesserungen, die man natürlich in den Release Notes nachlesen kann.

Scheele: Was steht auf der Roadmap für Grails? Welche Erweiterungen sind für die nächste Major-Version geplant?

Rocher: Wir planen eine kurze Iteration für Grails 1.3 mit dem Ziel Groovy 1.7 zu unterstützen. Das sollte Ende März passieren. Dann wird man auch Grails-Plug-ins in Standard-Maven-Repositories veröffentlichen und aus diesen herunterladen können – das ist wichtig für Organisationen, die ihr existierendes Maven-Repository verwalten und kein neues Repository-Format einführen wollen – derzeit verlangt Grails das noch.

Für Grails 2.0 liegt der Fokus auf einer stärkeren Modularität. Dafür wird Grails echte Runtime-Modularität unterstützen, so daß Grails-Plug-ins zur Laufzeit gestartet, gestoppt und aktualisiert werden können. Wir werden uns dieser Sache in der zweiten Jahreshälfte 2010 annehmen.

Abgesehen davon wollen wir, dass Grails stabil bleibt und das Plug-in-Ökosystem weiter wächst. Einige Grails-Plug-ins sind schon in der Planung, es wird also ein spannendes Jahr.

Teil 1   Teil 2   Teil 3   

Anzeige

Kommentare

Gravatar Trepper 29.01.2010
um 18:56 Uhr
Meiner Meinung nach sollte der Schwerpunkt ganz klar auf Qualität gelegt werden. Grails hat eine gute Architektur, Grails hat viele Funktionen, aber Grails hat leider auch viele Macken: http://jira.codehaus.org/browse/GRAILS Ich würde längere Release-Zyklen begrüßen. Es ist doch jetzt schon absehbar, dass durch Grails 1.3 mit Groovy 1.7 wieder einiges an Problemen hinzukommt. Danach sollte es erstmal eine längere Phase geben, wo die Qualität verbessert und nur Fehlerbereinigungen herausgegeben werden - bis der Issue Tracker irgendwann mal keine offenen Fehler mehr enthält. #zitieren

Anzeige

zurück zum Seitenanfang