Spring Roo, ¿competencia para Grails?

Interesante lo de Spring Roo. No lo conocía pero he llegado a él a través de la lista de Grails.

El link de arriba, el oficial, la verdad es que no deja nada claro que es Roo (el nombre parece que está todavía abierto). Según la descripción de esa página, pues casi que podría ser cualquier cosa. Pero bueno, básicamente Spring Roo viene a ser la alternativa Spring a Ruby on Rails o Grails. Es decir, un framework creado bajo los principios de convención frente a configuración y que aprovecha al máximo Java y Spring.

Hace un par de días, uno de sus autores publicó esta entrada en su blog donde muestra como construir una aplicación web Java totalmente funcional en solo 11 comandos. Vamos, muy en la línea de cualquier tutorial de grails o rails pero siendo todo Java, sin nada dinámico. En la misma entrada hay un link a la primera versión descargable de Roo por si lo queréis probar.

Ni que decir tiene que el framework está totalmente centrado en torno a Spring, Maven, JPA, muchas anotaciones, el soporte de REST de Spring 3.0 y AspectJ, siendo este último lo que se utiliza para introducir el llamemos "dinamismo" en la aplicación. La verdad es que de buenas a primeras a mi esta propuesta se me antoja muy pero que muy interesante. Especialmente por las ventajas de ser estático en cuanto al soporte del entorno de desarrollo, que es lo que a mi más me atrae. ¡Pero dónde estabas hace un año por favor!

En esta otra entrada de blog comentan algunas impresiones sobre Roo extraidas del keynote de Rod Johnson en la SpringOne.

Bueno y ahora la pregunta, ¿y por qué Spring Roo si SpringSource acaba de comprar G2One y por consiguiente tiene Grails entre sus proyectos? Graeme Rocher contesta en la lista de Grails.

We're working on a formal FAQ to help answer some of these questions, but fundamentally SpringSource is about enhancing developer productivity and those who cannot move to Grails (due to corporate policy mandating Java for example) shouldn't suffer from an unproductive environment hence the existence of Roo. Ultimately whether you use Grails or Roo you're going to be using Spring so we don't necessarily see them competing.

Now Roo can only achieve so much within the limitations of a statically typed language and in fact does most of its tricks through AspectJ and code generation. We hope that it is a gateway drug so that users eventually move to Grails and experience the full productivity benefits of both the Groovy language and the Grails framework. Until then people sticking with only Java at least have Roo as an option.

La explicación tiene todo el sentido del mundo. El único problema es que no evita que se trate de dos frameworks muy parecidos. ¡Y ambos hechos en Java! Con la única diferencia de que Grails soporta y requiere groovy. No sé yo si mantener los dos tiene demasiado sentido, por lo que esto siembra algunas dudas. ¿Podrian converger en el futuro? Dejo abierta la pregunta por si alguien quiere opinar.