As a Grails developer, Spring Roo seems to be more heavily promoted and easily integrated into other deployment platforms than Grails.
- Spring Roo is supposed to be supported fully by the Google App Engine. http://www.vmware.com/cloudportability/index.html
- Heroku for Java uses Spring Roo as a their example for integrating Spring MVC while not officially supporting Grails at all. http://devcenter.heroku.com/articles/spring-mvc-hibernate
Anecdotally, Roo also has a much nicer shell than Grails.
So how does Roo really compare to Grails? Given the lowered barrier of deployment for Roo, would it make sense to use Roo for new projects instead of Grails?
In this series of posts, I’m going to try going through the Spring Roo 1.1. Cookbook by Packtpub and try port the recipes in the book to Grails.
This would allow me to see any advantages offered by Roo over Grails.
CH1. Getting Started with Spring Roo
Create an application
C:\roo-cookbook\ch01-recipe>roo</p> <p style="padding-left: 30px;">roo>project --topLevelPackage sample.roo.flightapp --java 6 --projectName flight-app
grails create-app flightapp
Importing a Project into IDE
roo> perform eclipse</p> <p style="padding-left: 30px;">roo> perform command --mavenCommand idea:idea
grails integrate-with --eclipse --intellij --textmate --ant
roo> logging setup --level DEBUG --package ROOT
You need to modify Config.groovy and play with the Log4J DSL – http://www.grails.org/doc/latest/guide/3.%20Configuration.html#3.1.2%20Logging
You can also use Burt Beckwith’s AppInfo plugin that gives you a GUI for editing logging, database setups, etc.
Viewing Property Files
roo> properties list --name log4j.properties --path SRC_MAIN_RESOURCES
No similar mechanism. Properties files are stored in Config.groovy and BuildConfig.groovy and application.properties. Vim them.
Managing properties files
roo> properties set --name log4j.properties --path SRC_MAIN_ roo> properties remove --name log4j.properties --path SRC_MAIN_
Use an editor on the three files mentioned above
Creating a Java class
roo> class --class sample.roo.flightapp.service.FlightService --rooAnnotations
Normally works with groovy domain classes.
grails create-[ domain-class | service | controller ] sample.roo.flightapp.flightService
Moving existing Spring projects to Roo / Grails
Change toString to @RooToString.
Change @Serializable to @RooSerializable.
Change all setters and getters and annotate with @RooJavaBean.
No straightforward path. The last project I tried this on took about a month of development time.
You can reuse all your beans and all your hibernate mappings via the mechanisms included in this chapter ( http://grails.org/doc/latest/guide/14.%20Grails%20and%20Spring.html ). However, converting a Spring app into Grails is not trivial.
Adding attributes to a Java class
sample.roo.flightapp.domain.Passenger roo> field string --fieldName firstName
No easy way via the console. Edit the domain class files directly.
Creating a Java Interface
roo> interface --class sample.roo.flightapp.service.FlightServiceIntf
Not generally needed
Creating application artifacts from Roo Script
roo>script --file ch01.roo --lineNumbers
Grails offers a grails interactive command. A way to do this would be to pipe in your grails commands to grails interactive.
From the first chapter, it feels Roo offers easier integration with Spring. So if you have a large Spring application and want to move to a better framework without throwing away all your code, it seems like Roo offers much better possibilities.
I also liked the way in which Roo allows you specify fields in the command line, it’s very Rails like. I think it summarizes a slightly different philosophy in the way the shells are designed. The grails shell seems to expect you to work with property files and edit config files via a DSL.
Being able to configure logging in the command line is very cool. Grails is very weak in this area right now, and getting logging right has been an endless source of frustration in most projects I have worked on.
I didn’t like the verbose syntax for some commands of Roo. It felt very much like maven commands were taken out a pom file and thrown together. Compared to Play or Grails, which have commands that are closer to the action, they just felt a little clunky.
Overall, starting up an application in either platform felt very similar. As a Grails developer, it didn’t feel there was something absolutely awesome offered by Roo that would made me switch to it right away. In fact, some of the reliance on interface and annotations reminded me of the smelly experiences working with Spring.
It does highlight a few things that might be improved within the grails shell. Being able to add fields and constraints, and logging conventions via the shell might make a good addition to grails 2.0. Overall, Roo didn’t impress me as much as Play or Rails. But we will see as we continue further in this experiment.