Kai WaehnerIn this article, I will tell you about my experiences with Spring Roo. I will give recommendations when to use Spring Roo and when not to use it (yet).
What is Spring Roo?
“Spring Roo is a lightweight developer tool that makes it fast and easy to deliver instant results. Best of all, you code 100% in Java and get to reuse all your existing Java knowledge, skills and experience. You’ll like it – and have plenty of fun too!” (http://www.springsource.org/roo)
Many introductory articles exist already, just use Google if you do not know Spring Roo yet. In a nutshell: Spring Roo is a Java-based tool (using the SpringSource Tool Suite which is based on Eclipse). It uses AspectJ to simulate many features of Grails and other frameworks with dynamic languages to improve the developer experience.
Spring Roo is awesome for CRUD-Clients!
You can create a CRUD application within minutes to create, read, update and delete data. I recommend Spring Roo for CRUD applications because of a good community and a powerful vendor (compared to other CRUD frameworks such as Roma Meta Framework or OpenXava).
Personally, I would prefer Grails, but if you want to create CRUD applications with Java, then Spring Roo is the best alternative.
Spring Roo is good for learning Technologies!
Spring Roo is also good for learning technologies because you get a working example in seconds, and you can create more complex stuff within minutes using the Roo Shell. Then you can learn and understand how Spring Roo uses these technologies.
Of course, Spring-based technologies such as Spring MVC or Spring Security are supported very well. Also JEE standards such as Bean Validation or JPA are supported. Besides, many further technologies are supported, e.g. GWT, JSF, Vaadin, Flex or Google App Engine. Actually, many of these addons are not production-ready yet – but Spring Roo is young and I am sure that many improvements will happen because of the large community.
Spring Roo is NOT good for complex Projects (yet)…
Please be aware, that this is my personal opinion due to my experience with Spring Roo: If you want to build something really complex, then you should use technologies such as JPA, GWT or Google App Engine without Spring Roo, because Spring Roo is not ready yet for this kind of project, and thus will probably create more questions than answers…
One exceptional case: If you want to realize an application which uses especially or better just Spring frameworks, then you might start your project with Spring Roo. It can be a huge help in the beginning of a project.
Conclusion: Spring Roo is a nice Tool => Become a Part of the Community!
My final conclusion: You should know Spring Roo, because it is nice, but you should also know when to use it and when to use something else. Use it to create CRUD applications or to learn technologies. Do not use it (yet) for complex, large projects.
Spring Roo is young and has a large community plus a powerful vendor. You should participate and become a part of the Roo community to make it better and production-ready (this does not mean you have to commit code – I do not commit code as well – but even if you only read the JIRA issues and vote for your favorites helps the community).
So, if you never used Spring Roo yet, try it out now!
Best regards,
Kai Wähner (Twitter: @KaiWaehner)
21 comments
I also wrote a blog of my first impression of Spring Roo (http://opentoast.blogspot.com/2011/04/my-first-impression-of-spring-roo.html). Pretty much the same.
Thanks for the article! Would you be able to say a little about what would make a project sufficiently ‘complex’ such that you would not want to use Spring Roo? Where does it particularly fall down?
Hey Ross,
in my opinion, it falls down when you have to realize more than just CRUD. Of course, you can customize everything by yourself. Actually, you even still have the possiblity to use e.g. the “finder”-feature of Roo to create finders.
Nevertheless, if you have to create a lot of stuff besides CRUD, you are mixed in between “what to do with Roo” and “what to do without Roo”. You can also get stuff out of AspectJ into your Java code. Thus, governance and maintainability is much more complex if you use Roo for some stuff and no Roo for other stuff.
Try out e.g. GWT with Roo. If you create a CRUD application with 5 entities and relationships, you get about 200 (or maybe only 50 classes, but toooo many!). That is fine if you just need CRUD, but if you want to customize some masks, it is no fun and time-consuming.
Some other missing features are e.g. the limited Maven structure (mentioned by Yuan already) or a simple undo-button for the Roo console. If you mistype something in the Roo console, you do not really know what Roo does (due to its “magic”). I asked in the Spring forum about this issue, but the best solutions were:
– using the roo script to re-create to former state (but the roo script only uses the roo.log, and this log only saves commands from the Roo shell, but no changes within the IDE, e.g. if you add a new field to an entity within Eclipse)
– using a repository, e.g. GIT, and do a commit often. If you mistype you can revert your project 🙂
I think an undo-button is necessary, soon. Not even for complex projects, but even for simple ones!
Roo is on a good way, but I would not create anything else than a CRUD application with it at the moment.
Best regards,
Kai Wähner (Twitter: @KaiWaehner)
Well, any complex project starts from little, and you can always use Spring Roo for prototyping. When the project grows and reaches certain stage that you want to use something and Roo cannot support currently, you can easily remove Roo. I think no support for multi-module maven project structure (https://jira.springsource.org/browse/ROO-120) will cause you trouble when your project becomes “complex”.
Just my 2 cents.
Yuan
Hey Yuan,
sure, you can do “Prototyping” with Roo and remove Roo it afterwards! This is mentioned often when you hear or read about Spring Roo, but:
– why do you need to create a prototype for a CRUD application? It can just create, read, update and delete data, there is no need for a prototype.
– if you need more (GUI) stuff, how would you create this “prototype” with Roo?
– you can remove Roo, but you still have a Spring application. So, it is only good if you want to create a Spring application, not if you want to create a Java SE or Java EE application, right?
– also if you want to create a Spring application: after you remove Roo, you have “Roo naming conventions and patterns”, again I mention GWT as good example (although I know that GWT is one of the worst parts of Roo at the moment). If you want to realize a large project, you may have to refactor a lot, and then the benefit (i.e. quicker project startup) is gone.
Your hint about the limited Maven structure is also a good point, thank you!
Best regards,
Kai Wähner (Twitter: @KaiWaehner)
Very good questions. Although I just started to learn Spring Roo two weeks ago, I try to discuss from my experience:
Currently Roo generates SpringMVC CRUD application. But I bet in near future with more and more Roo add-ons are developed by SpringSource or third party developers, we can generate more advanced applications, like Jave EE or GAE/GWT. Roo provides a foundation for a future set of rich RAD tools.
And IMO I found Roo is best for domain layer coding, it saves me lots of time when I’m designing business domain model. I agree no undo is not very convenient. Quite often I just copy log.roo and clean it up and run again from scratch, and I feel it is OK for me. If it is a typo in field name, you can fix it in Java code directly and Roo will fix the aspectj code automatically.
For UI, I agree it’s the weakest part of Roo now. I don’t like generated GWT code either. I’m waiting for Roo integration with WaveMaker. Let’s be patient and see what’s the next. I’m still learning 🙂
Anyway, good article and good discussion.
Yuan
Hey Yuan,
support for several web frameworks besides Spring MVC is already available: GWT, Flex and Vaadin. JSF is also in progress (using Prime Faces). Unfortunately, these alternatives are not as “stable” as Spring MVC. Let`s wait a year or so…
I think there will be no “real” Java EE support in Spring Roo, because Spring is a competitor to Java EE in many cases 🙁
Of course, parts of it are supported already (e.g. JPA, Bean Validation) or will be supported soon (e.g. JSF). But you will probably never create an EJB application with Spring Roo 🙂 But it would be great if I am wrong…
Best regards,
Kai Wähner (Twitter: @KaiWaehner)
I don’t like EJB and JSF, because of bad experience. Not logical, just emotional 🙂
I’m waiting for good support of GAE and GWT from Roo.
Cheers,
Yuan (Twitter: @jiwhiz)
Off-Topic 🙂 But probably, you have not used EJB 3 oder 3.1 and JSF 2.0, but some older versions (which really sucked)???
Best regards,
Kai Wähner (Twitter: @KaiWaehner)
I’d rather use a web framework that builds on the MVC architecture, that:
– truly supports agile system development.
– builds on the REST principles.
– communicates both html and json.
– lets me choose my favorite template language.
– has protection against cross-site request forgery.
– can be deployed using cloud services.
– has awesome documentation.
…out of the box!
Oh but wait! I’m already using Ruby on Rails! 🙂
groovy/grails, much better and you dont have to learn a new language like Ruby (yech!)
@jens,
There is a FrameWork that satisfacts all (IMO) the requisits you stated: vRatptor 3!!!
vRatptor 3 allows RESTfarian approach and/or friendly-URL’s; allow u to use the right method (POST|GET|PUT| etc.) for the suitable request.
vRatptor is a real HTML-friendly *(Web)MVC-frontController FrameWork, so easier to get compliant to W3C Accessibility patterns and thus is allready ready if you’ll want use HTML 5.
The only thing of Jave that u need to use is EL-Expresson Languange and JSTL. So, so if u use ‘<c:out' u already get "protection against cross-site request forgery"! ;-))
People like to use vRaptor(3) w/ jQuery, so JSON is quite welcome! 😀
IHMO, that's the brasilian 50 cents!
Thanks for sharing your experience. We use Spring roo for quick protoype applications and found it really useful. You are right it still has long way to go for becoming right choice for a large project.
Hello Kai,
What about a web app that…
1) Integrates Solr
2) Renders tons of images
3) Integrates master details views
4) Integrates Google maps
5) Generates PDF documents and real time charts
Is it complex enough for you?
You can visit my very first Spring Roo web app any time. I named World Almanac by jD. Link at http://75.127.101.146/worldAlmanac. I implemented WA 18 months ago.
Feedback is always welcome
B. Roogards
jD
Hi jD,
indeed this is a nice, more complex web app (though, it is still “just” a CRUD app). I think, your web app is not contradictory to any content of my blog post: Spring Roo is awesome for CRUD clients and learning new technologies. If you want to add more custom behaviour or optimize the view, then Spring Roo can be used to create a prototype (as you did).
Best regards,
Kai Wähner (Twitter: @KaiWaehner)
Hello Kai,
Tell me what is the not “just” CRUD app profile and I will implement an app using Spring Roo…
What about that?
Thank you for your comments on World Almanac by jD…
B. Roogards
jD
Hey jD,
well, I have to admit that it’s not that easy to find a good idea for a more complex Roo project. I think you cannot build any kind of individual rich internet application (such as Pokerstars).
But let’s think about other public, well-known sites which could be made with Roo. Do you think you can realize an application such as Facebook or Ebay with Roo and really gain benefits by using Roo.
I do not want you to rebuild them, but I think these are good (public) examples because they have several different views and areas, images, messaging, dropdown-boxes, popups, sound, video, integration of other apps like maps, and so on.
Can you create such an app, add, change and also remove features, do refactorings, customize CRUD stuff, refactor again, make it look different. And of course, it should not only work (as your demo app), but also look good – I do not mean fantastic, but at least no overlappings (as the texts in the charts of your demo app) or such stuff.
I am sure that you can realize such an app with Roo (you have already used many features in your demo app), but it will be more trouble and efforts than creating it without Roo IMO.
Don’t get me wrong: I really like Roo, but I do not think that you can create complex, good looking apps which you can sell to a customer in an affordable time.
Best regards,
Kai Wähner (Twitter: @KaiWaehner)
[As there are some technical problems with the comments function, I have to add jD’s comment as admin. Btw, I have to admit: Some really interesting links]
Guess what… yes you can. You better review the following link before closing on conclusions.
http://pragmatikroo.blogspot.com/2011/06/spring-rooyouth-web-development.html
http://pragmatikroo.blogspot.com/2011/04/spring-roo-view-composition.html
http://pragmatikroo.blogspot.com/2011/04/springt-roo-standard-screen-patterns.html
http://pragmatikroo.blogspot.com/2011/04/spring-roo-online-games-industry.html
http://pragmatikroo.blogspot.com/2011/03/jquery-mobile-and-java-in-spot-light.html
http://pragmatikroo.blogspot.com/2011/04/springt-roo-standard-screen-patterns.html
All of them built using “just” for CRUD Spring Roo.
I think that the fact of raising the bar by asking me implementing a site like Pokerstars probes that a least you have change you perception of Roo now. What you think?
B. Roogards
jD
Actually.. Spring Roo doesn’t fall down for complex projects. It isn’t a frame work. It’s a base spring configuration generator. That’s what you use it for. Boot strapping projects. When you want to use it in a multi maven moduled product you simply remove the spring roo, change the pom file to “jar” and include it like you would any Spring project. When the generator fails your left with a spring framework code base where you can still code anything that you would have coded had you just been using the spring framework straight up. It isn’t Grails. It’s a boiler plate configuration generator. That’s all it does. The UI’s it generates to me are really about continual integration and not intended for complex UI work. That said there’s nothing you can’t add after the generator has done what it does that couldn’t be added to any vanilla spring project. Hope this helps. I find that SpringROO is misunderstood. It’s not a grails competitor. It’s a vanilla boiler plate configuration generator.
The real thing that bugs me about these comments is.. You keep making ROO sound different then spring. Yes.. ROO creates Boiler plate code. Just like SQL or Oracle can generate DB creation scripts. But that certainly doesn’t mean that SQL or Oracle are merly limited to the generation. ROO at the end of the day is a SpringFramework based application. So what your saying really is.. Can I build a complicated application using the Spring Framework. Well the Spring Framework can do anything that JavaEE does. Including supporting JSF… Including supporting a grails application as a Back End layer API and using Grails for what it does… Serve as a controller markup language… And this can be true of many controller markups like supporting RUBY via a SAAS model.
The end of the day I don’t get your argument. Your saying I can’t generate an entire complex application doing nothing but ROO generation. I say.. So what? Does that really make generating typical and commonly written code useless? Id say not.
And… Please explain to me why you think Java EE (What ever version) is better then the Spring Framwork? Now that I don’t get. You can line the feature set up almost line for line. The spring framework at the end of the day is just configuration glue to commonly used open source technologies with a context loader and some useful inlined frameworks that can be used or not right down to a bridge for j2ee.. Or even.. Deployed in a j2ee application directly sense it’s embedded .
No.. ROO has the entire power of the Spring Framework and by osmosis the entire open source world of java. Comparing it to Grails or Ruby.. That’s not relevant IMHO. ROO does what it does.. Generates configuration. It uses Pom files.. So you can mod them to be used in a variety of ways. Changing “war” to “jar” in no way destroys the benefit of creating sane and industry approved configurations patterns for a complex tool set like the Spring Framework. And the real question is… Can you use Java to build a complicated site the answer is yes you can. ROO makes dealing with configuration details a little easier. Does that invalidate it because it can’t generate your whole app? If it did we’d be out of a job.