Oli's Blog

Letzte Woche hatte ich mir mal kurz Spring Roo (www.springsource.org/roo) angeschaut. Erster Eindruck:

• scheint so 'ne Art "Ruby on Rails for Java" zu sein
• ist eine Sammlung von "Best Practices" bzw. "Best Tools"
• Abhängigkeiten werden über Maven verwaltet

Spring Roo kommt zwar nur als 4MB große Zip-Datei daher, aber bereits beim Generieren des ersten Projekts werden jede Menge von Bibliotheken und Plugins runtergeladen (Maven lässt grüßen!). Dafür hat man dann eine voll funktionsfähige Web-Anwendung mit JUnit- und sogar (!) Selenium-Tests, das man als fertiges Projekt in Eclipse bzw. die Springsource Toolsuite (= Spring-IDE auf Basis von Eclipse) importieren kann.

Der ersten Begeisterung folgt aber schnell die erste Ernüchterung: sobald man anfängt, den generierten Code erweitern zu wollen, wird man sehr schnell mit den darunterliegende Techniken wie Spring, JPA oder Hibernate konfrontiert. So wurde ich beim Experimentieren mit der generierten Test-Klasse gleich mit Hibernates berühmt-berüchtigter LazyInitializationException konfrontiert, weil ich die Test-Methode nicht als @Transactional gekennzeichnet hatte. Auch bei Erweiterungen an den JSP-Seiten ist man ohne SpringMVC-Kenntnisse aufgeschmissen. Dies Spring Roo anzukreiden wäre aber unfair.

Fazit: Spring Roo ist aus meiner Sicht ein Framework, das in der Java-Welt schon lange überfällig war (auch wenn mit AppFuse ein ähnlicher Ansatz bereits existiert). Es hilf einem, in kurzer Zeit einen Prototypen aufzubauen und weiterzuentwickeln. Es entbindet einen allerdings nicht von der Notwendigkeit, über die verwendeten Technologien Bescheid zu wissen.