By profession, I am a Principal Consultant at Esberi, and by virtue I design and develop enterprise web applications. I love to travel, read and enjoy soccer. Off late I have hooked to management books, but this doesn't mean I don't draw or code anymore. Mohammed has posted 1 posts at DZone. View Full User Profile

Spring Roo Impressions

07.20.2010
| 7824 views |
  • submit to reddit

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.

References
Published at DZone with permission of its author, Mohammed Khan. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Pavel Tavoda replied on Tue, 2010/07/20 - 8:24am

If you want some robust generation tool which follows DDD try this one:
http://sculptor.fornax-platform.org
http://fornax.itemis.de/confluence/display/fornax/Sculptor+(CSC)

We are using it for production purposes in many projects

Niel Eyde replied on Tue, 2010/07/20 - 9:42am

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

Mohammed Khan replied on Tue, 2010/07/20 - 7:38pm in response to: Niel Eyde

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.

Mohammed Khan replied on Tue, 2010/07/20 - 7:45pm in response to: Pavel Tavoda

@Pavel Is there a way that Sculptor can generate Spring-BlazeDS project template based on the domain model ? Thanks for the shout.

Steve Hicks replied on Wed, 2010/07/21 - 3:25am in response to: Mohammed Khan

Hi

 

What version of Roo did you use? I have tried 1.0.2 and found it lacking a few bits but 1.1.1 seems to be more complete

 

One problem you mentioned I did not agree with, was the issue with generated code. As long as you do not need to edit this then this should NOT be an issue. For example, when using JAXB, there are many generated class but that has never caused me any trouble since I just use them

Pavel Tavoda replied on Wed, 2010/07/21 - 5:28pm

Don't know too much about BlazeDS but I don't expect nothing different than entities. BlazeDS should understand it. However you are right - now Sculptor have no direct support for BlazeDS.

Mohammed Khan replied on Fri, 2010/07/30 - 1:30am

@Steve I tried 1.1.0.M2 version of Spring Roo, also if you go about modifying AspectJ files it is overwritten as you move ahead with Roo.

Mohammed Khan replied on Fri, 2010/07/30 - 1:31am

@Pavel Thanks for the confirmation.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.