I’ve been playing around with Spring Roo. Roo is a Java developer tool. Essentially it’s a code generator for Java Spring projects that generates not only Java code, but can scaffold entire web database applications. Maybe you’ve seen one of those Ruby On Rails or Grails demonstrations that start with a new directory and create a fully functional web database app in about five minutes. You can do the same thing with Roo. And at about the same level of basic functionality. Except you wind up with an application based on Maven, Spring Core, AspectJ, a JPA provider such as Hibernate, and Spring MVC or Google Web Toolkit. Here’s a neat demo video of Roo that features GWT.
After doing the ten-minute tutorial, I used the roo command tool to build a new application from scratch. My application would have a database table of users, roles, and a mapping of users to roles. The idea was to have roles that are editable by an admin, a basic user management system.
I found it easy to create the domain model classes with roo commands, including the many-to-many mapping. Integration tests against a MySQL database were generated automatically. With one command I created the entire web tier. The app ran with the mvn tomcat:run command and allowed me to edit roles and users. Great! Next, one command added Spring Security. But there the automation stopped. I would have to do manual coding to integrate my persistent users and roles with Spring Security. Still, not bad.
Things to know about Spring Roo
- Relies heavily on AspectJ. Most of the generated code is in .aj files.
- Does not use DAO or service layer patterns. Model and Controller classes, mostly as aspects, contain all the logic.
- Depends heavily on Spring annotations.
- Uses REST URL patterns. For example, update uses HTTP PUT.
- Does round-trip code generation. You can add a field in a Java model class and roo detects this and automatically updates related aspects and web forms related to the entity.
- Uses hbmtoddl to generate the DDL. I’m not keen on defining my DDL in Java model classes, though.
- All artifact dependencies use Maven repositories maintained by Spring Source. Dependencies are automatically added to the pom.xml file. One benefit is getting OSGi compatible jars with manifests.
I’m undecided if I would try to use Roo for a new project. My concerns include:
- There’s very little Java code, and you’re not allowed to edit the aspect source.
- Unit tests are written as aspects. How do I write my own, say with Groovy?
- I would need to create a service layer for some things.
- I’m uncomfortable with code-generated custom SQL queries. How do I take back some control without a DAO?
- I would need to provide a way to load test data to the database.
- I would need to remove hbm2ddl.
My main concern is the risk involved in learning which parts I can customize by hand without breaking things. In short, as with many slick tools it’s easy to get started, but will take time to master.
Roo, like Rails or Grails, is opinionated. It starts out with standard approaches to a Java web database project, approaches that you have to learn — and with which you may not always agree. The key is understanding where lock-in could occur, such that your hands are tied by having used Roo. It’s not really clear what that risk is going in.