To be honest, I was planning a long article about why I used spring roo for a new project I am working on. It all looks so promising, man I had a very nice app in a few hours. The fact that it is coming from SpringSource always give a good feeling. Therefore I moved on. Than I had a few wishes that made we change the jsp files. I also had problems creating a composite relationship. Finally to become really productive you have to use the Spring Tool Suite. The biggest problem there is that I have to use eclipse. Well, sorry, not going to do that anymore. If you are not interested in stories why something is not good enough to use for certain people, you can stop now. If you are interested in my reasons to stop using it for now, please do read on. I do have to warn you, I have formed this opinion after trying it for two evenings.

Oke, lets move on. The fact that you are reading this can mean two things. You are interested in my opinion so you can comment on it that I am wrong :-), or you are just interested.

In short, these are the reasons why, explanation follows:

  • Have to start editing the generated jsps almost in all scenario’s
  • Compositions are not really supported
  • To much use of Aspects in a way you need tooling to actually code
  • Dynamic finders

The need to edit jsps

There are four jsps being generated: create, update, list and show. The problem starts when generating relationships. Than you want to print something from the related object. The toString method is used. It is possible to change this method, probably using annotations, but you do not want that. Therefore you have to change the jsp.

<div id="roo_theme_project">
    <c:if test="${not empty projects}">
        <label for="_project">Project:</label>
        <form:select cssStyle="width:250px" id="_project" path="project">
            <form:options itemValue="id" items="${projects}" itemLabel="title"/>
        <script type="text/javascript">Spring.addDecoration(new Spring.ElementDecoration({elementId : "_project", widgetType: "dijit.form.FilteringSelect", widgetAttrs : {hasDownArrow : true}})); </script>

Have a look at line 5, when you generate the code, the itemLabel property is missing.

Why is it bad that you have to change the jsps? Well you have to tell roo to leave these jsps alone. This is a very easy thing to do (you guessed it already, yes using an annotation). Of course you lose the advantage of roo code generation immediately.

I need compositions

Just as a refeshment, what is a composition? A good example is the order -> orderline example. An orderline has no meaning without the order. If your remove the order, the orderlines can be removed as well. An example for my project would be a task and a comment. Without the task, the comment has no meaning. Therefore you want to have a screen with an order that enables you to create an orderline.

Ahh, aspects.

Let me state, I do like aspects. They are of some very good use in some situations. I loved the approach of spring with @Aspect, and the aspects from within the xml configuration. Now the type of aspects are used that you really need tool support for. No way you can use intellij for instance to develop de roo based applications. The moment you need something in java code, you cannot really do it. Of course you can download the free Springsource Tool Suite. But than I’d have to use eclipse again. No thank you. There is also an approach that you can put all aspect code back into the java class. Somehow this does not feel nice, you loose the roo advantages.

Maybe the guys at JetBrains will jump on the roo thing, but of course you cannot be sure.

To give you an idea of what you cannot do, check the following screendump.


As you can see the getEstimate() method cannot be found, that is because it is in an aspect

privileged aspect Task_Roo_JavaBean {
    // removed most of the methods

    public java.lang.Integer Task.getEstimate() {    
        return this.estimate;        
    public void Task.setEstimate(java.lang.Integer estimate) {    
        this.estimate = estimate;        

Dynamic finders

Roo contains a mechanism to use dynamic finders. You can use finders based on all properties like: loadById, descriptionLike, descriptionNotNull. All nice, but how often are you going to use that? Usually you filter on multiple properties or even based on properties of classes in their relationships. Must admit that I am not sure if that is possible, but I think not. Than you start coding, well not, you need the free tool from spring source.

Is it all bad?

No of course not. The concept is pretty good. I like the shell with code completion. The hints in the shell. Probably the Springsource Tool Suite integration is very nice as well. But I have not tried it. The best part is that it is created from the ground up to be extensible and to keep coding while using Roo. Another thing on the defence of Roo, it is new. It is not released and we all know what SpringSource is capable of.

For now I stick with spring, experiment with spring 3.0 and the jsr for validation. Maybe do some more google app engine coding. Maybe try it again in a few months. One thing is for sure, trying it is cheap and fast. The development speed for the basic things is high. I have the feeling this is only valid for the first day, than you might be better of with you own IDE and frameworks to become productive.

Have fun coding

Why Spring Roo is not my thing
Tagged on: