This week's book giveaway is in the Agile and other Processes forum. We're giving away four copies of The Mikado Method and have Ola Ellnestam and Daniel Brolund on-line! See this thread for details.
Does Spring 3 in Action covers Spring code generation tools (such as Roo), and their applicability in real-world enterprise applications?
Thanks & Regards,
Debashish
SCJP2, SCWCD 1.4
Craig Walls
author
Ranch Hand
Joined: Sep 19, 2003
Posts: 301
posted
0
Currently SiA3 doesn't cover Roo. But...I *REALLY* want to add it. I like Roo...I like it a lot. And I'd like to have at least an appendix, if not a full-blown chapter, devoted to Roo. We'll see...if time allows.
Spring in Action - Unleash POJO power in your applications!
Modular Java - Discover the secret weapon to modularity on the Java platform!
XDoclet in Action - Your complete guide to code generation with XDoclet.
I have few reservations about the enterprise adoption of Roo:
Its not really possible to "unplug" Roo from the system "easily", the effort would be considerable and switching back & fro is not possible. It could be a huge headache from configuration management perspective (which files to check-in to your source repository, which not?) and from build perspective as well (which files should your developer touch? What happens if a Roo file is changed accidentally?)
I didn't like the reluctance on using the prevalent DAO pattern (guess there is a JIRA issue where people who want DAO can vote)
There is certainly a learning curve, its easy to run ready-made Roo scripts, involving simple CRUD screens, but building complex applications would really need much effort in creation of domain objects using Roo script and then customizing the application. IMHO I would rather have Roo generate the 'Admin" part of my application, for CRUD use-cases of master data, but I would rather code the client facing app myself.
Would be interesting to know your POV.
Craig Walls
author
Ranch Hand
Joined: Sep 19, 2003
Posts: 301
posted
0
Firstly, it is very possible (and not all that hard) to remove Roo from a Roo-generated app. It's a 3-step process and takes only a few minutes:
1. Do a "Push-in" refactoring (requires STS or Eclipse with AJDT plugin) to push the ITD stuff into the Java code.
2. Globally remove all Roo annotations (should be as simple as replacing "\n.*Roo.*\n" with "\n"...with RegExp turned on)
3. Remove the Roo annotations dependency from the pom.xml file.
Adding Roo back is fairly easy, too. But it's hard to get the project back to where it was prior to the removal of Roo, so old Roo-managed stuff will no longer be Roo-managed...even though you'll be able to move forward with Roo for new stuff.
The DAO stuff is a point of controversy, I suppose. No comment from me on that one.
The learning curve for Roo is almost zero...it's just easy to use. The key thing is to just know to ignore the ITDs and trust that they'll magically do their job. But, using a tool like Roo is no excuse for not learning Spring. It's intended to get you to where you're going faster...it's not intended to replace good development skills. So, you'll still need to know how to do the real work of building a real application. Roo just gets you to the point where you can do that a lot faster.
To close, just wanted to remind (since I didn't see this in the TOC), may be you would like to cover the Object/XML mapping feature in Spring. Good luck with the book!
0
