Wird Spring Roo erwachsen?

Projektstruktur – Single- vs. Multi-Module

Ebenfalls ganz oben auf der Wunschliste der Community war die Nachfrage nach flexibleren Projektstrukturen. Immer wieder wurde beanstandet, dass Roo nur die Entwicklung in monolithischen Maven-Projekten unterstützt, wo doch komplexere Anwendungen in der Regel den Code auf Submodule verteilen, wiederum meist nach Schichtenzugehörigkeit. Auch dies ist mit 1.2.0 behoben worden: Roo unterstützt nun nicht nur die Generierung von Modulen in Maven-Projekten, sondern hat natürlich auch die Fähigkeit, über Modulgrenzen hinweg Abhängigkeiten zu erkennen und wie bisher in den monolithischen Projekten auf Änderungen direkt im Code zu reagieren.

Zusammenarbeit im Team

Als regelmäßiger Beobachter der Roo-Meilensteine war ein internes Accenture-Team Erstanwender und Betatester der neuen Features für Schichten und Multi-Module-Projekte. Es wurde schnell klar, dass mit diesen und weiteren Erweiterungen zwar die Grundhürden für eine Verwendung in Accentures Spring-Projekten genommen, dafür aber neue Herausforderungen entstanden waren. Die gute Nachricht war: Roo bot uns endlich die Wahlmöglichkeiten, die wir brauchten. Gleichzeitig war das aber auch die schlechte Nachricht, denn es hieß auch, dass potenziell jeder Entwickler in einem größeren Team Roo anders verwenden kann. Damit erhöhte sich auch das Risiko von Flüchtigkeitsfehler. Repositories oder Active Record? JPA oder MongoDB? Spring MVC oder JSF? Zum Erstellen eines neuen Projektes braucht man nun nicht mehr nur ein Command, sondern je nach Komplexität mindestens fünf (Listing 2). Und in einem Projekt mit zwei oder mehr Modulen: Welche Artefakte gehören eigentlich in welches Modul?

Listing 2: Setup eines neuen Roo-Projektes mit zwei Modulen
> project --topLevelPackage com.foo --projectName foo --packaging pom
> module create --moduleName foo-domain --topLevelPackage com.foo --parent com.foo:foo:0.1.0.BUILD-SNAPSHOT
> jpa setup
> module focus --moduleName ~
> module create --moduleName foo-web --topLevelPackage com.foo --packaging war --parent
  com.foo:foo:0.1.0.BUILD-SNAPSHOT
> dependency add --groupId com.foo --artifactId foo-domain --version 0.1.0.BUILD-SNAPSHOT
> web mvc setup
Teamstandards mit dem Tailor Add-on

Spring Roo 1.3.0 wird ein von Accenture beigesteuertes Add-on namens „Tailor“ enthalten, um einige dieser neuen Herausforderungen zu vereinfachen. Dieses Feature erlaubt es sowohl Teams als auch einzelnen Benutzern, Standardwerte und Präferenzen für die Roo-Verwendung in einer Datei zu definieren, wiederzuverwenden, und miteinander zu teilen.

Das Beispiel in Listing 2 zeigt, dass man doch einige Eigenschaften im Auge haben muss, um ein noch relativ simples Projekt mit zwei Modulen aufzusetzen: welcher Packaging-Typ gesetzt werden muss, die Abhängigkeit zwischen dem web- und dem domain-Modul darf nicht vergessen werden usw. Wenn man Roo regelmäßig zur Erstellung neuer Projekte verwendet und immer wieder eine bevorzugte Projektstruktur verwenden möchte, kann man diese nun in einer Konfigurationsdatei tailor.xml festhalten und wiederverwenden. Basierend darauf kann dann auch definiert werden, welche Roo Commands welche Module als Ziel haben sollen: Entities, Repositories und Services sollen in diesem Beispiel immer in das foo-domain-Modul generiert werden, alle Frontend-Artefakte in das foo-web-Modul usw. Ohne eine Tailor-Definition müsste man vor jedem entsprechenden Command den Modulfokus wechseln (module focus – moduleName foo-web), was mühsam ist und auch schnell vergessen werden kann. Listing 3 zeigt ein simples Konfigurationsbeispiel für den gerade beschriebenen Fall. Abbildung 2 hebt beispielhaft hervor, wie eine Tailor-Konfiguration die Präferenzen eines Roo-Benutzers bestimmen kann.

Listing 3: tailor.xml für ein Roo-Projekt mit zwei Modulen

Abb. 2: Beispiel für ein Multi-Module-Projekt mit Tailor-Konfiguration
Fazit und Ausblick

Mit den neuen Features hat Spring Roo endlich die Muss-Kriterien für die Verwendung mit geschichteten Architekturen geschaffen. Der von Roo generierte Code wird trotzdem nicht immer den Anforderungen des jeweiligen Projekts voll entsprechen. Aber es darf nicht vergessen werden, dass das auch nicht das Ziel sein kann. Automatisierung macht süchtig, ist aber nicht immer pragmatisch – auch bei Roo muss man wissen, wann der Generator einfach nicht mehr weiterhilft und man selbst die Ärmel hochkrempeln muss. Insbesondere in der Präsentationsschicht wird das für viele Projekte der Fall sein. Je nachdem, wie weit die eigenen Architekturvorstellungen von Roo abweichen, kommt dieser Zeitpunkt früher oder später oder vielleicht sogar gar nicht. In jedem Fall hat man bis dahin auf sehr effiziente Weise eine solide Basis geschaffen.

Für mich sticht für die Zukunft vor allem eines heraus: das hohe Potenzial der Roo Shell als effiziente Schnittstelle zwischen dem Entwickler und den Technologien – nicht nur denen direkt im Entwicklungsprojekt, sondern auch denen im Umfeld (bestes Beispiel: Roos Cloud-Foundry-Add-on). Neben dem reinen Zeitgewinn ist nämlich nicht zu unterschätzen, dass die Shell auch dabei unterstützt, eine qualitativ hochwertige Basis zu schaffen und dem Entwickler unbekannte Technologien von Anfang an richtig einzusetzen.

In diesem Sinne beschreibt Alan Stewart, Spring-Roo-Projektleiter, die Vision für Roo 2.x so: „Während Roo 1.x weiterhin so effizient die Entwicklung von JPA-Applikationen unterstützen wird wie bisher, sehen wir für Roo 2.x eine bedeutende Richtungsanpassung: Roo als Werkzeugkasten für die Entwicklung von hochskalierbaren Anwendungen. Wir wollen Roo-1.x-Benutzer auf dem Weg von der traditionellen JEE-Entwicklung hin zur nächsten Generation von Anwendungen begleiten; Anwendungen, die in der Cloud laufen, mit NoSQL-Datenbanken und HTML5-JavaScript-Frontends, die mit allen Desktops und Mobilgeräten kompatibel sind.“

Was unterscheidet eigentlich Spring Roo von.
. Grails und Ruby on Rails?

Auch Grails und Ruby on Rails sind „Rapid Application Development“-(RAD-)Frameworks mit Command Line Interfaces. Trotzdem ist der Vergleich einer von Äpfeln und Birnen: Grails und Ruby on Rails generieren Groovy- bzw. Ruby-Code, während man mit Roo auf Spring und Java setzt. Der Entscheidung für eines der RAD-Frameworks muss also immer die Entscheidung für die zugrunde liegende Plattform Groovy, Ruby oder Java vorausgehen.

. Model-driven Development (MDD)?

Modellgetriebene Entwicklung charakterisiert sich per Definition durch eine hohe Abstraktionsschicht in den erstellten Modellen, was in der Regel zu unidirektionalen Iterationen von „Modelländerung > Generierung > Implementierung“ führt. Bei Spring Roo hingegen repräsentiert der Java-Code das Modell. Durch diese sehr niedrige, plattformspezifische Abstraktionsschicht verlieren die Generatoren einiges an Macht. Im Gegenzug gewinnt man ein fast Roundtrip-ähnliches Verhalten: Die Shell und der Code können parallel verwendet werden.

Birgitta Böckeler arbeitet als Softwarearchitektin für Accenture Deutschland. Aktuell unterstützt sie ein globales Architekturteam in New York („Accenture Foundation Platform for Java“) bei der Definition von Open-Source-basierten Architektur- und Tooling-Standards für Java-Projekte.
Kommentare

Schreibe einen Kommentar

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