Thursday, March 25, 2010

Thoughts on Spring Roo

I started playing with Spring Roo (V1.0.2 at the time of this writing) to see if it would be useful as a RAD tool. I have found several things I like, and some things I don't like. Roo is still pretty new, though, and a lot of the things I do not like may soon be fixed.

What I Like
I like the way Roo generates code. Generating aspects during code generation to augment the model objects is very imaginative and works really well. I like the way it all works together in SpringSource Tool Suite as well. The code generated is really nice.

I also kind of like the command line interface. It provides a simple way to create a model from scratch. As a lover of the shell from way back, it is a very comfortable environment to work in. The tab completion is brilliant and removes the learning curve of the commands for all intents and purposes.

The generated web controller classes are also very REST-like, which is very nice because it allows you to adapt them to a REST API very easily.

Other interfaces such as JMS, email, and security are very well done.

You can provide plugins. That is very nice, there is always a need to tweak or add functionality to a tool like this.

What I don't Like
The command line has no undo capability. Sometimes you make a mistake, and you really do need a way to go back sometimes and do something again. Even a course grained undo to drop an entire entity would help. You could then just create that single entity again. It would also be nice to have a recording of the whole session. This could be used to see exactly what was done, and maybe edit it and be able to play it back when mistakes were made.

Another problem with the command line is the requirement to completely grok your entire model before you start. I am usually unable to hold the entire model in my head without making mistakes inputting it to the command line, and so need to turn to some kind of UML modeling tool to help me conceptualize all the entities and parts. I guess you could do that anyway, and then use the command line to enter the model into Roo, but that seems like a duplication of effort. It would really be useful to be able to import a model (XMI) into Roo.

The relations between entities are also a little off in places. Many-to-many relationships work pretty well, but one-to-many is problematic and one-to-one seems to be non-existent.  The one-to-many relationships are very unintuitive to use in the generated web application. And a composing relationship, where the master creates and manages the life cycle of the many side, is not supported at all. It is possible to rewrite the generated code to do this, but it should be a possibility right out of the box.

I am sure these issues can be overcome in time.

Other Thoughts
On the topic of modeling, I think importing a model into Roo would be a big step forward in usability. Eclipse, the technology under STS,  already has fantastic modeling capabilities with it's modeling project, and that would seem to be an excellent starting point to be able to provide modeling support. Having the EMF meta-model available would be wonderfully valuable. It would be possible to use other tools to work with the model, and we would also be able to directly work with the model using the EMF APIs if we chose to do so. The command line could be transformed into something that actually builds up the model using the EMF meta-model APIs. EMF does not require a UI, so that code could still run outside of STS or any other IDE, preserving the goal of IDE independence.

Roo must also get better at its one-to-* relationships, and provide for a composing relationship. For example, consider two entities: Person and Address, where there is a one-to-many relationship between Person and Address. In a composing relationship when a new address is required you do that from the Person screen/object. You always navigate to the Address object via a Person, and you add and delete addresses vial a Person.

REST support needs to improve as well. The web controllers are already very nicely RESTful, but Roo needs a way to turn on and generate the full support for REST without the user having to edit the context files manually. The REST support will then need to carefully consider the one-to-* relationships and composing relationships to generate all the methods in the correct spots. For instance, the Person controller would add an Address to a person.

It is still a little too difficult to work with large models with Roo, but it is surprisingly easy to work with already, with many powerful features. I think Spring Roo is a very nice RAD tool so far, and I believe it will get better pretty quickly.