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"/>
        </form:select>
        <script type="text/javascript">Spring.addDecoration(new Spring.ElementDecoration({elementId : "_project", widgetType: "dijit.form.FilteringSelect", widgetAttrs : {hasDownArrow : true}})); </script>
    </c:if>
</div>

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.

NoCompileTask.png

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

Tagged on:     

32 thoughts on “Why Spring Roo is not my thing

  • March 2, 2012 at 5:51 am
    Permalink

    I’m in the Stone Age camp … jdk ant Context. Eclipse has an awesome array of plug-ins and can aid in test harness etc. but for development it hides too much from us.

  • October 7, 2011 at 4:53 pm
    Permalink

    Roo is a definite time saver for boot-strapping projects, especially for the data access tier. It also is a time saver for boot strapping the controllers and JSPs because it builds in the spring context wiring and support for I18n and it does it the “right” way so you have great examples to work from. Just as an FYI, I have several large projects running in production that were originally boot-strapped from Spring ROO.

    That being said, forget about the UI (jsps) ROO generates. Just use the controllers as templates and build your own UI. I was very surprised to see ROO uses dojo instead of jQuery for the javascript libraries, maybe it’s a licensing thing? Every company I’ve ever worked for uses jQuery but that is just my personal opinion.

    Lastly, I totally don’t get the argument, forget about the IDE and give me a good text editor and command line. Apparently those that subscribed to this point have the entire JDK memorized as well as every 3rd party library used in their apps. Not to mention code searches, visualizing class hierarchy structures, etc. Really, let’s just use a good text editor?

    • June 12, 2013 at 12:32 am
      Permalink

      I agree with Greg’s take on the generated UI. It might help you populate your data early on but it is hard to understand. I use Roo for the data access layer and for REST. For the front end I’m using Backbone/Marionette.js with talkes to REST quite well.

      Andrew

  • August 11, 2011 at 2:50 pm
    Permalink

    We have this requirement of using gwt with spring and hibernate in medium weight project.A proposal has been placed of using roo to combine all these frameworks.I am still fuzzy of this proposal as we have to stick with scaffolds of roo and of course aspectj and compositions as mentioned in this article goes against it.But there is sense of urgency from our clients and everyone is speaking of roo.So a simple question to all the experts here whats your opinion and any other suggestions that proves way worthy than the current one.
    Thanks for any replies.

  • July 5, 2011 at 9:12 pm
    Permalink

    Well, I must agree that composition thing sucks. JSPs not a problem for me, i change them completly anyway. I also think that interface as it is is quite useless up till now. still, quite nice tool, and probably the future is somewhere in it.

    • May 20, 2011 at 12:14 pm
      Permalink

      Well we are 2 years after the blog post and I still don’t like it. So I guess I was right. A lot of other people do like it. That is for sure.

  • January 20, 2010 at 3:00 pm
    Permalink

    What would be nice is to be able to add to an application, some lean libraries that focus on one thing each.
    I would like to be able to create an application with a tool like Roo, only to create it fast, then forget about Roo and code it further in Spring. I would then use a gorm.jar helper library to give me dynamic finders, and a coc.jar helper library to give me conversion over configuration so as to allow me not to explicitly wire up my application controllers with annotations (no Spring autowiring). And of course, all of this available on the command line. Coding with an IDE is a pain in the… neck. The name resolution offered by Roo on the command line is superb ! This name resolution is enough for me to ditch the IDE. I’d say Roo is one step done right. One more and we can dance !

  • January 15, 2010 at 11:31 am
    Permalink

    For people not seeing AspectJ tooling working: don’t forget that your IDE needs to know aspects are involved. I’m using Eclipse, and found that using perform eclipse in the Roo shell gave the Eclipse project its AspectJ nature, and then lo! code completion etc all worked fine.

  • December 11, 2009 at 3:30 pm
    Permalink

    Nope, same as before. As long as you don’t try to use ITD methods (like entity weaved methods such as find, etc) from java classes, the compiler doesn’t complain. But then that means writing real code with the tool will generate compiler errors. So until the AspectJ plugin for IntelliJ has ITD support we’re where we were.

  • December 11, 2009 at 1:48 am
    Permalink

    I am the cause of that confusion. Didn’t realize what I wrote in that blog entry and have to go back and correct it.

    That entry that says that IntelliJ ‘works pretty well’ with Roo was mine – at the time I was experimenting with the framework and seeing what could edit the files. The problem I had was that I got build errors, and it didn’t support ITDs directly. I was building using Maven and using IntelliJ as a text editor at that point.

    I am testing Roo RC3 and the newly released IntelliJ 9.0. It seems to be working (at least not giving me errors on the annotations). I’m going to mess with it and post an updated blog entry.

    Sorry for creating confusion.

  • December 4, 2009 at 3:01 pm
    Permalink

    Thanks to the Roo team for their command line interface. I think the command line is the only robust way to handle code.

    Eclipse is welcomed to the code production process when it is used with Maven.

    I too am not a fan of annotations. They look like they are not part of the code. As long as they can stay out of my way and of my sight I’m fine.

    We may need a good Oreilly book on Spring Roo to really see what it’s got for a punch.

  • November 7, 2009 at 2:38 am
    Permalink

    @Manoo Tige

    Your biggest problem is that your programming on windows. Unless you`re using Visual Studio and specially if your doing web development, stick to linux or mac.

    Windows console, including PowerShell absolutely sucks.

  • October 22, 2009 at 5:30 pm
    Permalink

    Why do we have to use command level tools? Tabs and auto-complete help would have been ok olden days.. why now? Everywhere we see GUI and mouse and all of a sudden, surprised to see this….

    Not that I am unfamiliar with c:\ prompt… I am one of the very few who still use all CP/M commands under Vista cmd.

    This ROO is might be good learning tool for people to start with,,, In real life, in large projects, I do not see any role for this! I may be wrong….

    • November 7, 2009 at 10:25 am
      Permalink

      I am sure it is not windows, but a mindset. If you only want to use an ide that is your choice. I know a lot of people that are much faster using command line and vim than others using eclipse or whatever IDE. I like to combine them to get best of both worlds.

  • August 12, 2009 at 5:41 pm
    Permalink

    Coding in Groovy is much more productive than coding Java, and that is why Grails is more productive than pure Java. Roo, such as Grails, tries to imitate the best practices of Ruby on Rails and, although Groovy is not far behind Ruby, Grails nor Roo can actually compete with Ruby on Rails. Roo even tries to imitate the name (Roo ~ RoR). What does Roo stand for? If you really want to be extremely productive, try Rails instead of Grails or Roo.

  • July 22, 2009 at 4:52 am
    Permalink

    @Jettro, thanks for your feedback.

    1. JSPs customization. As Stefan mentioned, we want to do the round-trip support for JSPs properly and ROO-8 is capturing requirements on this issue.

    2. Support for compositions. As Stefan mentioned, we already have support for this.

    3. Use of aspects. We believe the compilation unit separation is one of the most fundamental innovations in Roo, and I blogged about this in depth at http://blog.springsource.com/2009/06/18/roo-part-3/. It’s worth noting that standard Eclipse plus all Eclipse-derived IDEs already enjoy first-rate AspectJ support and as such automatically enjoy first-rate Roo compatibility. As an aside, Roo works entirely at the command line and doesn’t even need an IDE (eg I routinely test my Roo changes on projects at the CLI and don’t even import them into Eclipse as it’s unnecessary given I can run easily JUnit, Selenium, Tomcat etc all from the CLI). I also discussed the issue of IDE compatibility in some depth in the comments section of my blog entry, so rather than repeat it all again here I’ll link to that discussion: http://blog.springsource.com/2009/06/18/roo-part-3/#comment-167388

    4. Finders sophistication. As Stefan mentioned, we already have support for this.

    @Erik, both Grails and Roo represent SpringSource-endorsed and SpringSource-sponsored approaches to productively building applications on top of top of the proven Spring family of projects. We have both Grails and Roo because static languages (Java) and dynamic languages (Groovy) are different programming paradigms that each have their own unique advantages and disadvantages, and we wanted to offer a compelling productivity solution for everyone – irrespective of their preferred programming paradigm.

    Best regards

    Ben Alex
    Project Lead, Spring Roo
    Principal Software Engineer, SpringSource

  • July 13, 2009 at 3:34 am
    Permalink

    I just started using Roo, and in spite of my last comment I agree with you. And I don’t want to use Eclipse. A good editor, ant, and javac, and I am on my way.

    Eclipse makes me configure everything twice. Once for ant, and once for Eclipse.

    There are a million other reasons for me not to use it (but I don’t want to spend time listing them), and one reason for me to use it (my manager said so).

    Eclipse was highly criticized when it was IBM Visual Age, and later on when it was WebSphere Studio, but the moment that they named it Eclipse, and pretended that it wasn’t an IBM product it became well-loved? Excuse me?

  • July 13, 2009 at 3:26 am
    Permalink

    Here’s one other to use it:
    (1) Generate the application via Roo.
    (2) Stop using Roo completely.
    (3) Edit the generated code in order to make it do what you want.
    This way Roo saves some time, but doesn’t get in your way.

    Aspects? I don’t feel comfortable with them, because they make things too abstract. That said, I believe that they have become so prevalent, that I just need to get over it. :-)

  • June 29, 2009 at 8:43 am
    Permalink

    Stefan, don’t feel sorry, you cannot read all articles and most of the items have been given feedback by you on the forum.

    As for your comment, I do not really understand what you mean with 2 (the compositions). You are asking what to do if the composition (Comment) has a another life cycle due to dependencies on other objects. Than it is not a composition anymore. My point is that I want to be able to create the comment from the Task screen, not attach the task from the comment screen.

    As for 3 (the aspects) I already mention this possibility of moving the aspect code back into java, but than you loose roo. It would be nice if the roo script could do this step. Maybe it would be the last step, but than I do not have to download the whole eclipse tool suite, setup the project only to do this moving of aspect code.

    The finders part (4), hmm I guess I missed this option about the depth.

    Thanks for taking the time to write your response.

    I’ll try to come up with ideas for improvements. I wish someone could give me 4 additional hours a day :-), or something that I do not need sleep anymore.

  • June 29, 2009 at 8:19 am
    Permalink

    Hi Jettro,

    Sorry I just saw your article today :(. Let me quickly go through some of the points you raised:

    1. The need to edit jsps

    This is indeed inconvenient and we are aware of this issue. Please feel free to comment or even make suggestions on it on our Jira: http://jira.springsource.org/browse/ROO-8. We are looking into solutions to get this right rather than just putting something out there that does half the job.

    2. I need compositions

    Roo allows you to conveniently create compositions without the need to know on how to use JPA annotations. I think this is a nice feature. About deleting dependent parts of the composition. This is somewhat tricky, we have decided not to delete Java source code from your generated project as this would give the impression that Roo does black magic things (most people don’t like that). Also, what is Comment is used by other types in compositions, or you want to use it later on or standalone? You may have already implemented some custom business logic in there. I am sure you would not be very happy if Roo decided to remove your source code ;). All you have to do is to delete Comment.java and Roo will automatically clean up all the aspects it generated for it.

    3. Ahh, aspects

    This is indeed something that avery good tool vendor should support. You should note that the latest version of AJDT (Eclipse Aspects tooling) even allows you to push-in all java code residing in aspects so that you have a plain Java project.

    4. Dynamic finders

    If you take a look at the sample scrips Roo ships with you will notice that we support the generation of dynamic finders for multiple properties. You can even list them conveniently:

    roo>list finders for list finders for -class com.foo.Person -filter equals -depth 2

    This would give you all possible finder combinations which contain only the ‘equals’ keyword. Further it gives you all combinations of fields up to the depth you define (in this case 2).

    If you want to have finders which span multiple entities you can always open a Jira ticket for it and make suggestions ;).

    Regards,

    Stefan Schmidt
    SpringSource team

    • June 22, 2009 at 7:41 pm
      Permalink

      All I can say is that I tried the aspectj plugin, for me it is not working. I was using maia of intellij. As far as I can tell it does not work, at least not easy.

  • June 22, 2009 at 5:00 pm
    Permalink

    There may be a problem with Intellij’s support for Aspects, but I’d place the blame on Intellij, not ROO. It’s not like AspectJ is new/dead (IMHO). Personally, I think this blog shows some strong weaknesses in Intellij.

    Also, if you want to change/remove the toString() operation, all you need to do is comment it out in the .aj file. Or, you can just overwrite the method in your class. Both solutions work fine. So, you really don’t need to edit jsps. Ben put a new blog out (6/18) and he outlines both methods.

    As for the dynamic finders, I think it just depends on the application. It would be nice to have all the combinations available, but that’s quite a few finders to search on…I guess some will like the more options, while others not..

    • June 22, 2009 at 7:43 pm
      Permalink

      I am not blaming ROO, I am just giving my opinion why it is not working for me.

      I do not want to use the toString method to show a drop down list, because you might need the toString for other purposes that it is meant for.

      And I fully agree that some might light it, and others not (not only the dynamic finders).

      Thanks for the comment and for the other post, it is a good one.

  • June 15, 2009 at 7:41 am
    Permalink

    Can’t say I don’t agree on all points. However, I still like Roo, since I too are not affraid of Eclipse (or never had the guts to try IntelliJ :P).
    Roo is easy to extend so when the first release comes and they finally release some documentation about how to create an addon (already asked several times for it) new addons will come fast and/or you create your own so the generated code complies to your standards.

    I created a feature request (ROO-40) to make it possible to transform a non-Spring project into a Spring project, transform a Spring version <= 2.5 into a Spring version 3 project and transform a non-Maven into a Maven project. This should make it easier to use Roo on existing projects. Reading the feedback I got from Ben Alex these features might be included in the final release.

  • June 13, 2009 at 11:35 am
    Permalink

    @SNR, you’re wrong on 2 accounts.

    Firstly Roo is not pure Java, aspects are clearly not part of the Java spec.

    Secondly they do compete as Roo and Grails are both here to facilitate the creation of web applications on the JVM.

  • June 12, 2009 at 12:58 pm
    Permalink

    Sorry but if you are suggesting Grails you’re missing the point of Roo. Roo is not designed to compete with Grails it is a pure Java framework.

  • June 11, 2009 at 8:13 pm
    Permalink

    I guess I’ll still try Roo, as I’m not afraid of Eclipse :)

Comments are closed.