At Esberi, we widely used Spring MVC and other products from the SpringSource stable, to build enterprise web applications. Been an RIA consulting company by nature and heavily working on the Flex front-ends, Spring-BlazeDS Integration always comes handy, and regular components like Spring Security, JMS integration and ORM support using Hibernate, are regular nuts and bolts of a generic enterprise web application at Esberi.
The initial part of the project kick-off is spend on Project Configurations, which is kinda tedious to handle during the initial phases due to component versioning. Maven does come to rescue but misses on closed project component templates. This bring us to another exciting yet to mature project from SpringSource called Spring Roo. Spring Roo is RAD development tool, which makes life easy for J2EE developers to work with Spring based project configurations. It helps you build model/domain driven Spring projects and generates the code based on the model/domain specified. Its just not a code generetion tool, but does all the code plumbing to integrate various components like, security, jms, logging, mvc, testing etc. which means the developer concentrates more on the entities rather than component internals.
Spring Roo heavily relies on AspectJ and Maven for most of its behind the curtain scenes. My initial reaction when I got started with Spring Roo was “Holy Grails, it does make life easy.”, but after closing looking at the code generated, its meant for prototyping and not for production deployments (just like Adobe Flash Catalyst design-to-code conversion, ugly and fat). So it does what it promises, and then I had to roll up my blue sleeves to make the code production ready. When working with Spring Roo here are my realizations :
1. The usage scope of Spring Roo is limited, doesn’t makes sense in collaborative enterprise project development.
2. Good for simple data models, not meant for complex ones. Also the domain modeling needs be visually enabled as it is in case of SkyWay Builder.
3. Code back-tracking is a mess, developers just don’t write code in incremental fashion.
4. Hard to sync up code when modified with further Spring Roo generation, generated code overrides your customized code.
5. Been working with Flex/J2EE projects for quite sometime, I am used to DAO design pattern, sadly this is missing in the code generated by Spring Roo, for a good reason, but still I am a spoiled one. Will take some time to accept the change.
6. Generates unit test cases and integration test cases, makes easy for QA and relies on Selenium for web application testing. (GOOD)
7. Generates the web tier for you to perform object CRUD operations, and relies on Tiles framework. (GOOD)
Further I must say Spring Roo does impress me from the point that it makes project configuration easy and the ability to bring in your own add-ons, no more getting paranoid with WEB-INF XMLs and dependency management. Considering the project timeline of Roo, I am sure the best is yet to come, for now limiting its application to prototyping itself.
NOTE: I have still got to put Spring Roo to further testing scenarios. Will write on my experience evolution soon.
12 Comments on “Spring Roo Impressions”
You can track this conversation through its atom feed.
Hey, Good info. Cool!!
Posted on July 19, 2010 at 9:41 am.
@Satish Thanx man, how is Singapore treating you, and how is fatherhood coming along. Take care.
Posted on July 19, 2010 at 10:29 am.
Hey Khan,
How ya going?
This is a point that I really would like to read about every new framework instead of just showing CRUD examples which,in my own opinion, is a little bit far of the real enterprise world. That’s the reason I’m still sticking with Seam framework.
Congrats for the post!
Posted on July 19, 2010 at 5:35 pm.
you didn’t write what version you tested?
Posted on July 19, 2010 at 10:08 pm.
@tom Well I got my hands dirty with 1.1.0.M2 version. Hope this helps.
Posted on July 20, 2010 at 12:42 am.
Hi Mohammed,
Have you looked at MyEclipse for Spring. It’s a joint product from Genuitec (creators of MyEclipse) and Skyway Software (creators of Skyway Builder). I think addresses some of your points.
re: domain modeling
MyEclipse for Spring has the same domain modeling from Skyway Builder. Furthermore you can design your domain model using database modeling tools and then scaffold from the resulting tables into a variety of Spring applications. Of course you can also scaffold from pre-existing java beans or JPA entities.
re: DAO pattern
MyEclipse for Spring generates using the DAO design pattern. Tooling shouldn’t force you to adapt to your standards, particularly on such a fundamental pattern as the DAO pattern which has been advocated by Spring development practitioners.
re: AspectJ
MyEclipse for Spring generates web, service, DAO, and domain layers instead of aspects for layering applications. The AspectJ approach is very interesting, but many Spring developers feel that it leads to code and debugging complexity.
re: Maven
MyEclipse for Spring supports native Eclipse and Maven-based project layouts. Maven is a great technology, but your tooling shouldn’t be forced to use it.
re: enterprise applications
MyEclipse for Spring scaffolds Spring MVC, Spring Web Flow, Adobe Flex, GWT, and iPhone Web front-ends, and they all share the same service/domain/DAO layers. Furthermore MyEclipse for Spring doesn’t generate based on milestone or early access versions of any frameworks or libraries. It’s designed to generate full applications or application components that can be used in production applications today.
re: Flex front-ends
MyEclipse for Spring generates Flex front-ends with integration to Spring backend using Spring-Flex and BlazeDS. Furthermore MyEclipse for Spring supports entity relationships.
I hope that helps.
Regards,
Niel
Product Manager for MyEclipse for Spring
Posted on July 20, 2010 at 7:47 pm.
Seems like a very fair review. I agree w/ most of your points. Roo comes off interesting but it’s unclear (at least to me) how you move from generating code in green field development to developing with Roo during the enhancement/maintenance phase on such a project.
Posted on July 20, 2010 at 9:34 pm.
Hi Mohammed
Thanks for posting your thoughts on Spring Roo. Here are some brief comments in response to your numbered items:
1. It would be good if you could expand on what you consider is missing for enterprise project development. Most of Roo is aimed at the enterprise and we’re aware of it being used in some pretty large listed organisations with success. We’re always keen to improve and welcome your suggestions.
2. This is more a philosophical question, “how do people want to model?”. For a Java-first approach we’ve had full support for round-tripping since the first-ever release, so you can just edit your .java files. For a database-first approach we’re adding incremental database reverse engineering to Roo 1.1.0. For UML-first there’s http://jira.springframework.org/browse/ROO-46, but it only has 9 votes so far (versus 117 for database-first as per http://jira.springframework.org/browse/ROO-435). We prioritise features with the most votes. Also Roo focuses on being a round-trip-aware, command-line-based tool, as this is what we believe delivers the best usability for Java developers. Nevertheless a request for graphical tooling (as distinct from UML support) is being tracked at http://jira.springframework.org/browse/ROO-843 (although it doesn’t even have a single vote so far).
3. I’m not sure what you mean by code back-tracking. Roo supports incremental round-tripping, so you can edit your .java files at any time. If you make a legal edit to a .java file and Roo doesn’t recognize it, we consider that a bug in Roo and we’re happy to fix it (bug reports can be filed at http://jira.springframework.org/browse/ROO). Round trip support is covered at http://static.springsource.org/spring-roo/reference/html/usage.html#usage-usability.
4. Users shouldn’t customise *_Roo_*.aj files, although you are free to customise .java files at any time. Roo will never overwrite your .java file changes. You can use AJDT’s “Push In Refactor” feature to move members from a .aj file to a .java file if you’d like to take control of them (cut and paste also works just fine). Once you move a member from an .aj file to a .java file, Roo will no longer generate the member in the .aj file. You can read more about these usability conventions at http://static.springsource.org/spring-roo/reference/html/usage.html#usage-usability.
5. We discuss the reasons we don’t have DAOs at http://static.springsource.org/spring-roo/reference/html/architecture.html#architecture-dao. Nevertheless there is a popular enhancement request for DAO support at http://jira.springframework.org/browse/ROO-301. With 55 votes, we will add support to Roo for this (despite my architectural concerns as per the previous link).
I hope the above provides some extra information around some of the items you raised. Thanks again for having taking them time to share your thoughts. We appreciate the feedback.
Best regards
Ben Alex
Project Lead, Spring Roo
Posted on July 21, 2010 at 4:22 am.
Hi @Ben_Alex Thanks for taking out time for the clarifications, really appreciate it. As I said I am yet to put Spring Roo for further more testing, and will share my thoughts soon. Meanwhile my employer has arranged a Webinar for Indian J2EE Development Community, here are the event details http://esberitechtalk1.eventbrite.com/ . If you have any thoughts or messages to be shared kindly do let me know, and I shall do my best.
Thanks again and Take care.
Posted on July 21, 2010 at 5:08 am.
Hi @Niel
Well I haven’t tried MyEclipse for Spring, will give it a shot and post a review about it. Thanks for the highlight.
Posted on July 21, 2010 at 5:14 am.
@Mohammed, if you’d like my latest Spring Roo slides please feel free to shoot me an email and I’ll be happy to provide them. My address is balex at vmware com.
Posted on July 21, 2010 at 7:53 am.
@Ben_Alex Thanks for the extending support, I have written to you. Also can you point me to some documentation which would let us build add-ons for Roo, as we plan to build a Spring-BlazeDS JSR-286 portlet add-on. Looking forward to your response.
Posted on July 21, 2010 at 9:31 am.