Spring Roo


1 October 2012, by

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?

The easiest way to create a Roo project is using Spring’s own IDE, SpringSource Tool Suite (STS).  Spring’s own documentation also has a step by step guide if you prefer using the command line.

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.

Add-ons

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

Tags: , , ,

Categories: Technical

«
»

4 Responses to “Spring Roo”

  1. The most useful thing about Roo, I found, was that it will bootstrap a Spring MVC app for you. Unlike Rails, Spring MVC needs lots of configuration just to get started, and it’s not at all clear what needs doing if you don’t have a working app to copy. While the scaffolded pages are of limited value (personally I found the scaffolded controllers to be wrong in several ways), having a scaffolded XML config as a starting point is very helpful. It’s also easy to strip Roo out once it has bootstrapped your project for you.

  2. Ridvan Gyundogan says:

    Some thoughts on how we use Roo:
    We use it with Spring MVC, Spring Roo has some well organized tag files like form.tag, table.tag etc. The tags don’t exactly fit all our requirements, but if we change something we change it on a single spot – the tag files which all CRUD screens use.
    So now we have, localized string screens, parent child screens etc by changing the roo tag files.
    We have something like 60 Entity classes with all kind of OneToMany and ManyToMany relations, If we had to do this ourselves would be impossible.
    Well the drawbacks:
    Poor support for aspectj ITD in the eclipse plugin.
    There is no good documentation of how to write more complex roo plugins which generate ITD .aj files.

  3. Chris Harris says:

    Hi Ridvan, thanks for your comments! We have also found AspectJ to be a bit unstable, and lacking in tool support.

  4. Ridvan Gyundogan says:

    @Chris – .aj is stable once compiled. The ITD plugin gives me pain especially when I start the roo.sh in a console or change the files outside the STS. In this case full rebuild of the workspace in STS fixes the issue. I am talking about Spring Roo 1.2.1.


Leave a Reply

* Mandatory fields


5 − = four

Submit Comment