Spring Roo – Grails only with Java… or more?

On the surface Spring Roo is first of all a type of Grails for developers who are not allowed to use Groovy in their projects – for whatever reason. Roo enables them to build on projects quite fast, it supports the evolution of domain objects, offers scaffolding, etc. – but all on a pure Java basis. One can stress that projects generated and developed with Roo do not depend on Spring Roo. Instead, they are running completely independent – an important advantage, if one wants to carry on developments without Roo as well or if one wants to transfer them to other environments. Among other things there is support for JPA, Hibernate and the various Spring modules. If one takes a closer look one could think Roo is a kind of architecture wizard for Spring products: It promotes the sufficiently well-known Best Practices of Spring in automatically creating the corresponding class and interface hierarchies and in appropriately creating the corresponding annotation, aspect or XML based configurations, etc. Roo here particularly supports a complete round tripping and is able to take over again code changes into the basic meta model. Furthermore it knows how to deal with this model in order to reach the goals. This allows a faster and easier start into modern (and thus more complex) Spring and JavaEE projects, because Roo also generates much useful around its own classes – for instance methods for counting, loading, saving and searching for objects, expanded Debugging information via toString() and more.

But if one goes a step further and seizes, for example, the opportunity of the session breaks at SpringOne to talk to Ben Alex, the SpringSource Project Lead behind Spring Roo who is beaming with enthusiasm, one discovers many more interesting Aspects which let Spring Roo appear as an interesting basis for manifold extensions. For example:

  • It internally disposes of a polished meta model for mapping the various project artifacts and their dependencies. This provides very detailed information on the source code level, which can also be used for continuing actions (for example within the scope of project architecture refactorings as one idea).
  • It manages a meta data system also supporting transactional changes. Internally Roo needs that in order to take back changing operations concerning artifacts if a later change fails for whatever reason.
  • It uses a polished event system to keep informed about changes concerning artifacts and being able to give continuing actions a push.
  • It provides a plug-in concept which is – according to Ben – optimized for easily implementing extensions for Roo. SpringSource is hoping for a growing community here propelling Roo to further heights analogous to the Grails Community.

With regard to tools Spring Roo first of all offers a programming environment based on command lines (if one wants to call it that way) similar to Grails. This command line orientation is, however, provided on the basis of an own Shell that offers considerable comfort with regard to operation and manifold possibilities of support for the Roo user. In particular there is a strongly context-sensitive instruction for the Roo user. This reaches from implicitly useful context relations to code completion up to the level of parameters and even to the fading out of currently non sensible combinations of commands and parameters. This approach is so efficient that an excluded “Spring Shell” for the use on the same paradigm is said to become part of other projects as well in the future. The SpringSource dm Server with its administration console is surely a first top candidate here in the Spring Portfolio. But Grails could certainly also profit from that. Besides this Shell Roo will also experience constantly intensifying support within Eclipse in form of a closer integration into the SpringSource Toolsuite (STS) in the future.

Summed up, Spring Roo presents itself as a comparatively interesting project for the pure Java/Spring World: If it is possible to reach an only approximate dynamic as with projects such as Grails, it could easily result in an interesting eco system for standardizing and accelerating Spring projects. The approaches appear to be considerably more mature and modern than the classical Maven-based procedure. Especially the presence of a meta model for all artifacts regarded should turn out to be extremely helpful in developing interesting extensions. For me, refactorings of Roo-based projects on the basis of a project artifact level seem to be a very exciting topic more than ever – the next weeks and month will show where Roo (which is, by the way, derived from “kangaroo”) will jump to.

Links for more information

[1] Spring-Roo-Project

[2] Blog-entry of Project Lead Ben Alex

On the surface Spring Roo is first of all a type of Grails for developers who are not allowed to use Groovy in their projects – for whatever reason. Roo enables them to build on projects quite fast, it supports the evolution of domain objects, offers scaffolding, etc. – but all on a pure Java basis. One can stress that projects generated and developed with Roo do not depend on Spring Roo. Instead, they are running completely independent – an important advantage, if one wants to carry on developments without Roo as well or if one wants to transfer them to other environments. Among other things there is support for JPA, Hibernate and the various Spring modules. If one takes a closer look one could think Roo is a kind of architecture wizard for Spring products: It promotes the sufficiently well-known Best Practices of Spring in automatically creating the corresponding class and interface hierarchies and in appropriately creating the corresponding annotation, aspect or XML based configurations, etc. Roo here particularly supports a complete round tripping and is able to take over again code changes into the basic meta model. Furthermore it knows how to deal with this model in order to reach the goals. This allows a faster and easier start into modern (and thus more complex) Spring and JavaEE projects, because Roo also generates much useful around its own classes – for instance methods for counting, loading, saving and searching for objects, expanded Debugging information via toString() and more.

But if one goes a step further and seizes, for example, the opportunity of the session breaks at SpringOne to talk to Ben Alex, the SpringSource Project Lead behind Spring Roo who is beaming with enthusiasm, one discovers many more interesting Aspects which let Spring Roo appear as an interesting basis for manifold extensions. For example:

  • It internally disposes of a polished meta model for mapping the various project artifacts and their dependencies. This provides very detailed information on the source code level, which can also be used for continuing actions (for example within the scope of project architecture refactorings as one idea).
  • It manages a meta data system also supporting transactional changes. Internally Roo needs that in order to take back changing operations concerning artifacts if a later change fails for whatever reason.
  • It uses a polished event system to keep informed about changes concerning artifacts and being able to give continuing actions a push.
  • It provides a plug-in concept which is – according to Ben – optimized for easily implementing extensions for Roo. SpringSource is hoping for a growing community here propelling Roo to further heights analogous to the Grails Community.

With regard to tools Spring Roo first of all offers a programming environment based on command lines (if one wants to call it that way) similar to Grails. This command line orientation is, however, provided on the basis of an own Shell that offers considerable comfort with regard to operation and manifold possibilities of support for the Roo user. In particular there is a strongly context-sensitive instruction for the Roo user. This reaches from implicitly useful context relations to code completion up to the level of parameters and even to the fading out of currently non sensible combinations of commands and parameters. This approach is so efficient that an excluded “Spring Shell” for the use on the same paradigm is said to become part of other projects as well in the future. The SpringSource dm Server with its administration console is surely a first top candidate here in the Spring Portfolio. But Grails could certainly also profit from that. Besides this Shell Roo will also experience constantly intensifying support within Eclipse in form of a closer integration into the SpringSource Toolsuite (STS) in the future.

Summed up, Spring Roo presents itself as a comparatively interesting project for the pure Java/Spring World: If it is possible to reach an only approximate dynamic as with projects such as Grails, it could easily result in an interesting eco system for standardizing and accelerating Spring projects. The approaches appear to be considerably more mature and modern than the classical Maven-based procedure. Especially the presence of a meta model for all artifacts regarded should turn out to be extremely helpful in developing interesting extensions. For me, refactorings of Roo-based projects on the basis of a project artifact level seem to be a very exciting topic more than ever – the next weeks and month will show where Roo (which is, by the way, derived from “kangaroo”) will jump to.

 

Thomas Biskup
Thomas Biskup

What do you think?

JAX Magazine - 2014 - 05 Exclucively for iPad users JAX Magazine on Android

Comments

Latest opinions