1 October 2012, by Sean Hale
Spring Roo is a tool for rapid Java application development. It claims to offer industry standard solutions to common problems. It’s been gaining popularity and we have trialled it on a number of our projects with mixed success. Here’s a quick set of answers to questions that you might find yourself asking when starting a new Spring project.
What can I do with Roo?
Roo offers you scaffolding features similar to those found in web frameworks such as Rails. You describe an entity with fields and from this it will create CRUD (Create Replace Update Delete) views and controllers using standard Spring conventions. These are kept in sync so if you update the fields on your entity then it will update the rest of the application. With this you can create fully functional web sites from scratch in a very short period of time.
When should I use Roo?
Firstly, Roo is probably not something you want to retro-fit to an existing application. Although this is possible, it will be time consuming and offer little value.
If you are thinking about starting a new project then your application may be a good fit for Roo if it matches the following criteria:
- CRUD heavy – e.g. a management console.
- Sticks to Spring conventions. If you need to deviate from convention (URLs, variable names, view names) this is doable but you’re probably better off without Roo.
- Simple UI requirements. If you need fancy AJAX / JS binding then the standard crud pages will hold you back.
Roo was a big time saver for one of our clients when developing an internal admin console for managing a database-driven website. We had an entire proof of concept (UI, security, auditing, REST + AMQP services) ready in less than 2 weeks.
How should I use Roo in my project?
Roo can be left in your application indefinitely but this is generally not recommended. You should aim to remove it as soon as you have nailed down a basic domain model (probably within the first few weeks of the project). This process is easy to do and is described here.
The end result is a set of auto-generated Java classes, views and configuration files with no indication that Roo ever existed. Make sure you allow at least a few days to tidy up the auto-generated code and tweak the architecture a bit to your liking. Be warned that you will probably find a lot to change/remove along the way.
How can I create a Roo project?
So, should I use Roo on my Project?
Roo can be either a huge time saver or a hindrance depending on the project. In general, if you want to deviate significantly from the cookie-cutter Roo template (either right from the start or later on in the project) then you should avoid Roo. If you do decide to use Roo then keep in mind that the longer you leave it in the project, the more headaches you are building up when you try and remove it later (and you will almost certainly want to remove it because you will find places where it is simply not configurable enough). If unsure then it’s probably best to avoid Roo and roll your CRUD the old fashioned way.
Interesting Roo Features
Creating Java Entities From a Database (Database Reverse Engineering)
The DBRE add-on can be pointed at a database and it will generate the corresponding Hibernate entities. To test this functionality we pointed it at an existing Oracle schema which didn’t follow standard Hibernate naming conventions. Most of the code had to be heavily modified to the point where it would have been faster to just write the classes from scratch. If you have the option it would be much easier to create the entities in Java code first and use Hibernate’s auto-DDL feature to create the schema.
Additional functionality is provided in the form of add-ons. We didn’t use them but they may be useful in your project, for example:
- Solr Integration for Search
- JSON REST service
- Cloud Foundry integration