Spring Roo – Grails only with Java… or more?

Thomas Biskup
Spring-Roo

In his keynote at the SpringOne at the end of April in Amsterdam Rod Johnson introduced Spring Roo as the new project of SpringSource, the manufacturer of the well-known Spring Open Source Framework. What is behind that?

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.

 

Author
Thomas Biskup
Thomas Biskup, QuinScape GmbH. Advisor, Trainer and Senior Architect for Enterprise Solution Deveolpment, object-oriented methods, portals, web applications and model-driven software development.
Comments
comments powered by Disqus