Whats to Like About Grails? mucho!

Plugin architecture
We have a couple core plugin projects we use as inline projects.  One provides core web standards, layouts, security setup.  Set it and forget it.  When I want to create a new app thats all taken care of - and no I am not copying the code.  I am reusing all web code, resources in an architected way.  Images, CSS, layouts, javscript, domain classes, controllers, everything!  One line in my config file adding the plugin project as one of the plugins for my project and I have it all.

GORM
DSLs are where its at.  At first I have to say I thought the idea of learning mini languages all over the place seemed ridiculous. But if you stop and think about it every problem domain brings some learning curve.  You might know Java and annotations but that doesn't make you a hibernate expert.  DSLs when done right bring the learning curve down.  They provide the proper abstractions and expressiveness for the problem domain.  So DSLs like GORM constraints or mappings, once you've worked with them a little, become surprisingly simple.

Plugin central!! It is amazing what is out there for Grails plugins. If all the plugin did was resolve the dependencies for adding APIs they would be good to have - but they do way more.  They bridge/adapt that technology to GRAILS -augmenting! the framework.  The plugin architecture opens up Grails to doing just that.  A good example is the render plugin.  Need to output PDF?  Install the render plugin and you get a renderPDF dynamic method added to your controllers which works much like the render method you are already familiar with.  Contrast that to adding flying saucer to your java project!

Groovy
Closures and much more. Having a dynamic modern language enables so much - i.e. GORM recently added named queries to domain classes.  Check it out if you are using grails - great stuff!

Porting Spring MVC to Grails

Model
Model comparison
Spring mvc really doesn't tie in a specific model but hibernate with JPA anotations is probably the choice for most.  We had hibernate with xml configs plus DAOs.  GORM is much more elegant - less code - less classes.  No validators for example.  GORM has named queries - think of SUPER Domain classes!  Between service and domain  classes I see no need for a DAO.

Model porting
Switching you model tier to grails will involve the most work.  It would be possible to reuse hibernate DAOs and just create service classes that use them as a first step.  Best to just port it to GORM to gain all capabilities of Grails domain classes.

Best approached as both a bottom and top down.  Rewrite all hibernate domains to GORM then rewrite all spring service classes to Grails service classes and add functionality to domain classes as required by service class.   Finally add validators (constraints) to replace spring validator classes to domains.

Model Results
Elimination of many layers, classes (ie, DAOs, Validators).  Service classes are similar but much less code.  Using groovy and GORM dynamic features brings a lot of power.    Much more readable.

View
View comparison
GSP more flexible, sitemesh layouts are intuitive,  grails tag libs that can be called as methods (avoids nested tag issue), Grails tag library very good.  Smart tags that pass through tag attributes that are not part of tag (ie. class="css-class").  Big plus for grails  is handling of partial pages (templates). Can be done with tiles but has to be configured as an entire page.  Grails makes ajax trivial (whether returning xml, Json, or partial html).

View porting
This was by far the simplest part of porting.  Simply rename your JSP to GSP and switch your JSP tags to Grails tags.  Your javascript should be relatively unaffected as long as you have the grails tags create the same markup.  If you used tiles or other dynamic templating switching to sitemesh shouldn't prove too difficult.  We did employ tiles but nothing too crazy.  Switching to sitemesh was a breeze and I much prefer working with sitemesh - very intuitive - no config files.

View Result
No configuration - ie. tiles.  GSP tags more powerful but all in all GSP is similar to a JSP.

Controller comparison
Spring MVC has a few ways to handle model in the controller. What I dislike the most is the annotation of a method to have it return  part of the model.  So your controller has this mix of methods that have very different purposes.  All in all somewhat similar although handling different output formats (eg. JSon) much easier in grails - same handler method can handle different outpout.

Controller port
Fairly straightforward.
Result 
Grails controller much more concise and intutitive.  Easy to maintain - logic for particular request in one method (closure actually).