Eine Historie mit Ausblick – Neue Features seit Version 1.2

Wird Spring Roo erwachsen?

Birgitta Böckeler

Seit dem ersten Release von 2009 hat Spring Roo schnell an Popularität gewonnen. Es ist das beliebteste Tool, um schnell und effizient Spring-Webapplikationen aufzusetzen und zu entwickeln. Dennoch sehen Kritiker Roo hauptsächlich als schnellen Weg zum Prototypen und als eher ungeeignet für den kontinuierlichen Einsatz in großen Anwendungen. Seit Release 1.2.0 hat das Spring-Roo-Team nun signifikante neue Features herausgebracht, die einen genaueren Blick wert sind.

Spring Roo [1] ist ein „Rapid Application Development“-Framework, das bei der Entwicklung von Spring- und Java-basierten Webanwendungen unterstützt. Wie auch andere vergleichbare Werkzeuge aus diesem Bereich kann Spring Roo auf Basis von Entitäten die nötigen Codeartefakte generieren, um eine Weboberfläche zum Erstellen, Lesen, Ändern und Löschen dieser Domänenobjekte zu bauen. Dieses Vorgehen wird auch „CRUD Scaffolding“ genannt (von Create, Read, Update, Delete). Mit der „Roo Shell“ können Entwickler mit der Codebasis ihres Projekts interagieren: Über simple Commands lassen sich Java-Code und Konfigurationsdateien manipulieren, von der Shell unterstützt durch intelligente Command Completion und kontextsensitive Hilfe (Beispiele für Commands in Listing 1).

Listing 1: Ausschnitt aus Roos „Pizzashop“-Skript: So interagiert der Benutzer mit der Roo Shell
// Create a new project
project --topLevelPackage com.springsource.pizzashop
// Setup JPA persistence using EclipseLink and H2
jpa setup --provider ECLIPSELINK --database H2_IN_MEMORY
// Create domain entities
entity jpa --class ~.domain.Base --activeRecord false --testAutomatically
field string --fieldName name --sizeMin 2 --notNull
entity jpa --class ~.domain.Topping --activeRecord false --testAutomatically
field string --fieldName name --sizeMin 2 --notNull
entity jpa --class ~.domain.Pizza --activeRecord false --testAutomatically
field string --fieldName name --notNull --sizeMin 2
field number --fieldName price --type java.math.BigDecimal
field set --fieldName toppings --type ~.domain.Topping
field reference --fieldName base --type ~.domain.Base

Zwei innovative Eigenschaften zeichnen Spring Roo neben dieser Shell besonders aus: Zum einen beschränkt sich Roo nicht nur darauf, auf Benutzereingaben in der Shell zu reagieren, sondern läuft außerdem kontinuierlich als Helfer im Hintergrund. Dadurch kann Roo auf Änderungen reagieren, die der Entwickler manuell an der Codebasis vornimmt. Die zweite Besonderheit ist die Art und Weise, in der generierter Code von manuell editiertem Code getrennt wird. Diese Trennung war schon immer eine der größten Herausforderungen im Design von „aktiven“ Codegeneratoren. Aktive Generatoren zeichnen sich durch die Fähigkeit aus, Teile des Codes immer wieder neu zu generieren, ohne dass dadurch manuelle Änderungen überschrieben werden. Traditionell wird dieses Ziel meist mit geeigneten Design Patterns in der generierten Anwendung erreicht. Das Spring-Roo-Team kam erstmals auf die Idee, den manuellen und den vom Generator kontrollierten Code durch den Einsatz von AspectJ-Features zu erreichen. Details zu diesem Vorgehen lassen sich sehr gut unter [2] nachlesen. In diesem Kontext ist vor allem wichtig, dass Roo Hand in Hand mit dem Entwickler an der Codebasis arbeiten kann, ohne dass sich die beiden in die Quere kommen. Weiterhin kann Roo jederzeit aus dem Projekt entfernt werden, durch einen einfachen, automatisierten Refactoring-Schritt, in dem getrennter Code wieder zusammengeführt wird.

Herausforderungen: Spring Roo in großen Entwicklungsprojekten

Über 30 000 Mitarbeiter arbeiten weltweit für Accenture an der Entwicklung von Java-Anwendungen für Kunden aus allen Industrien. In der Regel werden diese Anwendungen in großen, meist verteilten Teams gebaut. In der „Accenture Foundation Platform for Java“ [3] fasst Accenture Open-Source-basierte Architekturstandards, Tools und Best Practices zusammen, um Java-Projekte zu beschleunigen und bei der Standardisierung ihrer Architektur zu unterstützen. Im Rahmen dieses Programms stellten wir uns Mitte 2011 die Frage, ob Spring Roo als Rapid-Development-Werkzeug für diese Art Projekte empfehlenswert ist. Das wurde vor allem anhand von zwei Kriterien deutlich:

  1. Ist die generierte Referenzarchitektur angemessen für große Applikationen?
  2. Eignet sich Roo für die Kollaboration in großen, verteilten Entwicklungsteams?

Eine entsprechende Analyse ergab damals noch entscheidende Defizite. Im Folgenden wird beschrieben, wie mit Spring Roo 1.2.0 inzwischen Punkt 1 signifikant nach vorne gebracht wurde, und wie Punkt 2 durch ein neues Feature in 1.3.0 erstmals adressiert wird.

Tabelle 1: Die beschriebenen Spring-Roo-Charakteristika vor und nach Release 1.2.x im Überblick

Vor 1.2.x Heute
Schichtenarchitektur

  • Persistenz mit „Active Record Pattern“
  • Keine Unterstützung für Repositories
  • Keine Generierung von Services
  • Generierung von Repositories und Services wird unterstützt
  • Auswahl verschiedener Typen von Spring Data Repositories (JPA, MongoDB)
Flexible Projektstrukturen

  • Roo nur nutzbar in monolithischen Maven-Projekten, keine Unterstützung von Maven-Modulen
  • Unterstützung für Maven-Projekte mit mehreren Submodulen
  • Keine Abhängigkeit mehr von Maven als Build-System
Team Collaboration

  • Fixe Referenzarchitektur mit relativ wenig Variationsmöglichkeiten, Teamarbeit unproblematisch
  • Mehr Features, mehr Optionen, mehr Variationen: Neue Herausforderungen für die Kollaboration
  • Möglichkeit Teamstandards und -Defaults mithilfe der „Tailor“-Erweiterung zu definieren.
Geschrieben von
Birgitta Böckeler
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.