Spring Roo..is it worthwhile?

It's no secret that attaching a well recognized brand to the name of a product (software or not) is a wonderful recipe to get some public attention. In my opinion, Spring Source (see) abuses it. It's not alone though, just take a look at Google's portfolio. Nonetheless, beyond the name (which I like), Roo looks like a little gem. It's like extracting some of the best parts of AppFuse (project kickstart) and Grails (scaffolding) and joining them in an unobtrusive tool. Let's see how it performs.

Obviously, it goes without saying, Roo shines in new projects as it will help mostly in the first stages of the development. Well, that was like saying that Roo will be specially interesting in a project using both Java and the Spring framework. Whatever...

Let's begin creating a project from scratch then. After opening the command line tool (there's a plugin but I prefer to always use the command line at the beginning to ensure everything will build later on) the user just needs to type

project --topLevelPackage org.internna.test

And Roo will take care of creating the folder structure of a valid Maven web project. Include there the pom file and some sweeties like a fully preconfigured Spring environment and the logging system. Let me stress this, if Roo's only mission would be to help with project creation it couldn't do any better already. Just by doing the above, Roo is useful in any project using Spring. Of course, this includes a trade off, the defaults may not suit you but chances are that the changes you'll need to provide will be minimal (after all, they are, purportedly, best practices) and much less work than doing everything manually from scratch (try the logging setup command). There's something that worries me more though and something important. The current approach is monolithic. Where is the multi-module support?

At this point, I have to admit that I'm pretty glad with the decisions taken about third party products. Maven, JPA/Hibernate, the Spring suite, JSPs all fit my style and that's something I value. People from other environments may find this ecosystem exogenous.

We've seen it already but I will state it clearly here: Roo is a Code Generator. And I do it because I HATE code generators. I avoid them like a plague actually. When I hear the words code generation I flinch. And then? Well, Roo wraps to modes of code generation: passive (once and forever) and active (incremental). For now, I'll stick to the first one and let Roo generate and manage all those tedious configuration files (like, say, persistence.xml) while leaving more advance uses to the future..whenever I feel comfortable. You may not feel the same but beware that choosing the second model, while powerful, it also (tightly) binds the application to Roo.

One last thing that didn't really convince me was the way that Maven is handled. I'm not sure why I have to type perform test instead of the usual mvn test. Or why I must exit the tool to launch a mvn tomcat:run. Obviously there's room for improvement in this area. The integration between both should be seamless.

All in all, it gets the approval seal around here. There are some rough edges yet mainly in the Maven support. And, of course, all the active code generation area is something I need to evaluate very carefully. But it's a 1.0 version and I expect improvements. It's sad they dropped the multi-module support, that bit alone will heavily hamper the adoption for medium to large projects.