This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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.
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.
Joined: Sep 19, 2003
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.