Jul 28th, 2009, 08:50 AM
Where's my code?
I took the recent version for a quick test drive just walking through the example.
I've been looking for a good crud generator that used Spring MVC and this might just be it. However, I do have some concerns.
Spring Roo generated code is highly abstracted through aspects. I don't really have a sense of an application anymore. I also wonder if this even debuggable?
Can Spring Roo handle existing model beans as input? I really don't want to through hundreds of command line input commands to set up a complex project that prob has existing model objects or could be set up easily that way through Eclipse.
I suppose I know the answer to this, but is it conceivable that Roo will generated a straight model, service manager factory, dao factory, web controller type app with the actual physcial artifacts as .java files.? This as opposed to everything being an aspect? I guess I could rephrase the question to: does Roo require you to adopt an aspect oriented code style? It seems that way to me. I'm prob old fashioned.
Jul 28th, 2009, 09:37 AM
Maybe this blog post (read the comments too) from Ben Alex helps you to understand better Roo“s using of AspectJ.
I had the same concerns that you have a time ago, but after reading the blog and playing with Roo i“m not concerned anymore
Hope this helps
Last edited by raul.arabaolaza; Jul 28th, 2009 at 09:42 AM.
Jul 30th, 2009, 06:50 AM
You can use Roo with an existing project, provided it follows the basic structure of a normal Roo project (which in 1.0.0.GA really just means a standard Maven project).
You do NOT need to use the Roo shell to create your entities. This is just a convenient way for most people to do so. You're certainly free to annotate your existing entities and other Java source classes and Roo will respond. Don't forget Roo never changes any file unless you explicitly ask it to at the shell or via the incorporation of an @Roo* annotation. So it's safe to load the "roo" shell in any directory, as it won't change anything until asked to.
Regarding creation of aspects, the reasons for that are detailed in my aforementioned blog entry. They are totally debuggable and offer a great experience, with long-term add-on version upgrade support and much more. You can use AJDT's "push in refactoring" to eliminate the aspects from the project and convert them to stock-standard Java classes. We see this as a major use case for Roo: starting a project but then continuing manually. It's the whole absence of lock-in which is central to the Roo philosophy. We can only achieve that by using relevant standards (JPA, JSP etc) and mainstream tools (Spring, Maven etc) and emitting code that is of the same quality as if a professional developer had written it by hand. In particular Roo does not require you to use its shell, continue with aspects if you don't want them, or live with anything less than really nice architecture and code.
Jul 30th, 2009, 07:10 AM
Thanks for that. I'll give Roo a spin on an existing model and see what happens.
Aug 4th, 2009, 12:48 PM
Well, gave it a bit of a try. I got a controller generated based on an existing model class that I copied to the model directory. Trying to generate a finder resulted in a "not an entity" error message. Not so strange, because my model class is a regular jpa class.
I guess the question is:
is it possible to get the full benefit of Roo based code generation with an existing model?
If not, is it possible to strip a model class down to its bare essentials and then use it as input for Roo to Roo-afy it? I wasn't able to do this by new persistent etc because Roo kept saying it already existed.
BTW, as interesting as project scaffolding is, I'm also very interested in the CRUD UI generation potential.
Aug 5th, 2009, 02:28 AM
I have succesfully used an existing model class (that“s it one not created by Roo) as a model in a Roo“s Application, including crud generation and all parafernalia.
Did you annotated your class with @RooEntity to make it Roo-aware??.