Einsatz und Grenzen von Spring Roo

Seite 2: IDE- & Framework-Unterstützung

Inhaltsverzeichnis

Wichtiger ist die Anbindung an die IDE. Grundsätzlich kann man mit Spring Roo jede IDE verwenden, die AspectJ unterstützt. Wenngleich hier theoretisch alle drei großen IDEs im Java-Umfeld (Eclipse, Netbeans und IntelliJ IDEA) eingesetzt werden können, empfiehlt sich die in Eclipse integrierende, kostenlose SpringSource Tool Suite (STS), da diese einige zusätzliche Features implizit anbietet:

  • integrierte Roo-Shell
  • Unterstützung für Spring Context und automatische Code-Vervollständigung
  • erweiterter Maven-Support für Spring-Templates durch diverse Archetypen
  • API-Editoren, beispielsweise für Spring WebFlow, Spring Batch oder Spring Integration
  • Refactoring von Roo-generiertem Code, beispielsweise durch "Push-in" einzelner Teile eines Aspekts in die zugehörige Java-Klasse, um diese dann per Hand ändern zu können.
  • Entfernen der Roo-spezifischen Inhalte. So kann man nur den Prototyp mit Spring Roo erstellen und für die weitere Entwicklung dann eine "normale" Spring-Anwendung verwenden.

Auch die anderen IDEs arbeiten an besserer Unterstützung für Spring Roo. IntelliJ IDEA besitzt beispielsweise ab der Version 10.5 eine integrierte Roo-Shell.

Das Haupteinsatzgebiet von Spring Roo sind sicherlich Webanwendungen. Sie lassen sich dank Web-Frameworks wie Rails, Grails oder Lift in wenigen Minuten erstellen. Allerdings muss der Java-Entwickler neben der Einarbeitung in das neue Framework zunächst auch die zugehörige Programmiersprache wie Ruby, Groovy oder Scala lernen. Hier ist Spring Roo eine interessante Alternative, da es die Entwicklung von Webanwendungen mit "Plain old Java" ermöglicht.

Das Web-Framework kann man dabei frei wählen, Spring MVC oder Vaadin bieten sich für klassische, serverzentrische Webanwendungen an, Flex oder GWT für Rich Clients. Ein Add-on für JavaServer Faces (JSF) ist in Arbeit. Und Add-ons für weitere Web-Frameworks sind sicherlich nur eine Frage der Zeit.

Für bestehende Entitäten kann mit einem einzigen Kommando in der Roo-Shell eine CRUD-Oberfläche generiert werden. So erstellt die Anweisung controller all --package ~.web eine Spring-MVC-Anwendung mit einem User Interface für alle Entitäten, während das Kommando gwt setup einen Rich Client für das GWT generiert.

Zumindest Spring MVC bietet bereits eine gute Integration in Spring Roo und ist einfach mit anderen Spring-Projekten wie Spring Security kombinierbar. Die Integration anderer Web-Frameworks ist noch nicht stabil genug, um sie schon in Projekten einzusetzen.

Als Beispiel sei hier GWT genannt: Die Code-Generierung enthält noch Bugs, beispielsweise funktioniert das Erzeugen der Oberfläche nicht immer erfolgreich – häufig ohne ersichtlichen Grund. Zudem generiert das System im Moment noch unzählig viele Klassen. Darüber einen Überblick zu erhalten und eigene Anpassungen vornehmen zu können, ist schwierig. Mit Einführung von Places und Activities ab Version 2.1 hat Google die Komplexität vom GWT noch einmal erhöht. Pro Entität werden zahlreiche Java-Klassen erzeugt, was Anpassungen und Wartung aufwendig macht. Leider wird auch die von AspectJ benötigte Inter-Type Declaration (ITD) erst in einer zukünftigen Version des GWT unterstützt. Vorerst setzt man daher ein Abstract-Concrete Model ein, was Entwicklern nur Änderungen in der abgeleiteten, konkreten Klasse erlaubt.

Weitere Funktionen wie die Integration von Spring Security oder Database Reverse Engineering (DBRE) unterstützt die Software noch nicht oder sie laufen nur instabil. Finder, also generierte Suchabfragen für Entitäten (zum Beispiel die Suche getAllProjectsById), erzeugen noch kein zugehöriges User Interface, wie es bei Spring MVC der Fall ist.