What Spring Roo is and What it is Not

Posted on 2013-12-16

This is a pretty old article. Instead of trying Spring Roo I suggest Spring Boot. If you're unfamiliar with it I suggest reading this blog post I made about it.

I just had my first encounter with Spring Roo. Encounter sounds like I had no choice in the matter, but it was my own decision. I had seen the name floating around for a long time, but it didn't seem to pop up as much as other Rapid Application Development tools. Why was this? "I like Spring, I should give it a try", I thought. This is my take on it.

Roo as a config generator

I don't like it when the main page of any product leaves me guessing as to what that product actually does. Spring Roo is culpable in this respect. It says a whole lot about nothing. IMO all they should have said was

Get up and running with Spring's most popular components, without writing boilerplate.

I would have given it a shot based on that alone, because I hate writing boilerplate, and I hate the huge amount of base context XML configuration. That brings me to my first gripe: no way to generate Java Configuration. I thought XML config would slowly be phased out as people adopted Java Configuration, but in Spring Roo it is the only way to set up your context. It has been added as a feature request.

Roo lets you generate complex config using simple commands from a specialized shell for the following components:

  • JPA backed by several providers (Hibernate, Datanucleus and OpenJPA)
  • MongoDB through Spring Data
  • Spring Security (Web)
  • A web framework of choice (Spring MVC, GWT and JSF)

Development support for your domain layer

When you watch the promo videos one thing seems to get a justifiable amount of attention is the use of AOP (AspectJ) to enrich your entity objects. Oh, did I not mention that? When you configure a persistence layer you can start defining entities that

  • have JSR 303 validated properties
  • automatic toString generating aspect
  • automatic getter and setter generating aspect
  • automatic persistence save/update/remove methods aspect
  • have relationships with other entities

I don't think I've ever really felt like writing the base domain layer code was very time consuming, but if you are already setting up boilerplate with Roo, then going the extra step and defining the entities does save you writing DAO's, which Spring Roo does not believe in. For the record, I agree. I've had to work with DAO's based on DAI(interfaces) with the argument that "we may one day want to switch vendors", but we all know that if that ever does happen, there is probably going to be a rewrite of massive scale anyway. Pointless abstractions suck.

Your objects get updated by the Roo shell and the shell detects your code changes. Once you have the entities setup and you're not targeting Google App Engine or using GWT, I think you should stop using Roo, but you can also use it for...

Scaffolding a web tier

This is a very powerful feature, don't get me wrong. The web layer includes a fully functional web application with CRUD style controllers and views. At that point it's only a matter of adding custom operations and removing unnecessary elements. You can have have your cake and eat it too... as long as you don't care too much about the view layer. The generated code can be influenced. The appearance tweaked, but looking at the sheer number of files that are generated by running web mvc all, I can tell that I'm not going to be happy plowing through it. Spring MVC can be nice and minimal, but that command gives you Apache Tiles, JSPX files and Dojo Ajax support. Nothing wrong with any of that. They are just not my personal choices. So the lack of standard out of the box options when generating the web layer is the biggest disappointment of Roo.

The GWT support is supposedly amazing, as it was written by the Google devs. Add to that the fact that you can use GAE's Datastore as a persistence provider for your JPA entities means that developing an enterprise ("You keep using that word. I don't think it means what you think it means.") application for GAE with minimal changes to the way you develop. I really like the free tier GAE platform for personal use webapps. It's a great target platform and I was always sad that it wasn't more VPS in nature. Requiring some tricks to get things like Apache Wicket to run on it.

Conclusion

Roo is amazingly useful for developers wanting to start a new Spring project that fits the generic webapp formula (View > Controller > Domain > Persistence). The scaffolding of the web layer can be customized, but this takes work. If you see the power of Roo and are sure to use it a lot, then investing the time into customizing the scaffolding will definitely pay itself back. If you're targetting Google App Engine and like Spring framework: Roo is for you.

However, if your webapp is going to use some custom view tech, then stop before you scaffold. Or optionally, setup the base web layer so you can get the Spring Security config for free, then remove the unneeded web artifacts. Also, if your webapp will use a persistence mechanism not provided by Roo, or if it doesn't need much persistence at all, then Roo will add very little to your productivity.