This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.
Theoretically it's possible to reverse engineer an existing database, but I haven't tried it with Roo. The way I'd approach it is to generate a Roo project, install JPA support via Hibernate, then use the Eclipse Hibernate plug-in to reverse engineer. Have it create your domain model within the Roo project and use JPA annotations. No need for getters/setters - just the classes and annotated fields are all you really need. Roo should theoretically then work as normal. Please let me know how you go.
Thanks for your reply. From a JUG someone told me to use Netbeans. I have generated JPA entities from the database, then I have generated JSF for the entites and now I have a generated CRUD with JPA + JSF. I think that is possible to generate even Spring MVC from the entities.
I didn't know that was possible to use eclipse too.
One consideration is the NetBeans generation is probably a one-time-only process (I can't confirm this, though, as I haven't investigated it myself). Still, it's these "build app from database" approaches offer round-trip support. I've used the Hibernate plugin for Eclipse and it didn't offer round-trip support at the time I used it.
One approach you might like to consider is generating the entities only, then deleting all the constructors, getters, setters, toStrings etc those entities include and let Roo build them for you (as well as the web tier). That way you get full round-trip support and an order of magnitude less generated code you'll need to maintain into the future. The application will also be Spring 3-based, offer RESTful URLs, Maven builds, integration tests, Selenium tests, easy installation of related technologies (eg Spring Security, JMS, email etc) and all the other benefits of using Roo. Naturally if it's just a quick app and you're happy with what you already have, there's no reason to change.
I'm certainly open to the community producing an add-on that can be used to introspect an existing database and produce a Roo script that represents a new Roo-based project or the change script for an existing project. A simple metadata introspection script is very easy, whereas it gets more complicated when composite primary keys, foreign keys etc are desired.