A Grails developer tries Spring Roo ( pt 1 )

Springsource/VMWare promotes two different application frameworks, Spring Roo and Grails.

As a Grails developer, Spring Roo seems to be more heavily promoted and easily integrated into other deployment platforms than Grails.

For example,

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

Roo

C:\roo-cookbook\ch01-recipe>roo</p>
<p style="padding-left: 30px;">roo>project --topLevelPackage sample.roo.flightapp --java 6 --projectName
 flight-app

Grails

grails create-app flightapp

Importing a Project into IDE

Roo

roo> perform eclipse</p>
<p style="padding-left: 30px;">roo> perform command --mavenCommand idea:idea

Grails

grails integrate-with --eclipse --intellij --textmate --ant

Configure Logging

Roo

roo> logging setup --level DEBUG --package ROOT

Grails

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

roo> properties list --name log4j.properties --path SRC_MAIN_RESOURCES

Grails
No similar mechanism. Properties files are stored in Config.groovy and BuildConfig.groovy and application.properties. Vim them.

Managing properties files

Roo

roo> properties set --name log4j.properties --path SRC_MAIN_
 roo> properties remove --name log4j.properties --path SRC_MAIN_

Grails
Use an editor on the three files mentioned above

Creating a Java class

Roo

roo> class --class sample.roo.flightapp.service.FlightService --rooAnnotations

Grails
Normally works with groovy domain classes.

grails create-[ domain-class | service | controller ] sample.roo.flightapp.flightService

Moving existing Spring projects to Roo / Grails

Roo
Change toString to @RooToString.
Change @Serializable to @RooSerializable.
Change all setters and getters and annotate with @RooJavaBean.

Grails
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

Roo

sample.roo.flightapp.domain.Passenger roo> field string --fieldName firstName

Grails
No easy way via the console. Edit the domain class files directly.

Creating a Java Interface

Roo

roo> interface --class sample.roo.flightapp.service.FlightServiceIntf

Grails
Not generally needed

Creating application artifacts from Roo Script

Roo

roo>script --file ch01.roo --lineNumbers

Grails
Grails offers a grails interactive command. A way to do this would be to pipe in your grails commands to grails interactive.

Conclusion

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.

6 thoughts on “A Grails developer tries Spring Roo ( pt 1 )

  1. Pingback: Pedro Newsletter 03.10.2011 « Pragmatic Programmer Issues – pietrowski.info

  2. Felipe Nascimento

    Nice work. Keep on the series….
    I think Roo and Grails both try to be an agile development tool/framework to the Java Platform. But one deliver a Java based app, while the a Groovy based one. Some companies would not allow anything but the Java language, so these should go the Roo path. The ones that allow other languages and still want the Java Platform and its benefits may choose Grails as well. I think grails is still more dynamic and simpler in its final application source code. While the tool to generate stuff is better in Roo, then final code is simpler in Grails IMHO because of groovy´s dynamic. Roo is a really smart way to get around the burocracy of Java Web Apps, but Grails is the “No Burocracy” Java Web App. I am a java web app developer, and I love Grails nowadays.
    Cheers
    Felipe

    Reply
  3. Kai Wähner

    I absolutely agree to Felipe’s comment.

    Besides, I think that no one will migrate a large, existing project to a Roo / Grails project. The most benefits of Roo / Grails are gained in the early stages of a project. I think Roo should be used especially for project setups and for CRUD applications (as stated in my blog: http://www.kai-waehner.de/blog/2011/04/05/when-to-use-spring-roo).

    I think Grails is much more powerful due to Groovy’s dynamic features and because it is much more mature. Roo may be a nice candidate for more complex projects in one or two years…

    Looking forward to more blog posts of this series!

    Best regards,
    Kai Wähner (Twitter: @KaiWaehner)

    Reply
  4. alexmc6

    Thanks! I’ve been learning roo for some time and wondered about Grails so this gives me some idea of the differences and similarities.

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s