Spring Roo 1.1.0 Interview

Ben Alex: ‘The GWT and Roo teams continue to collaborate to make the GWT support even better.’

Jessica Thornsby

JAXenter speaks to lead of Spring Roo, Ben Alex on the 1.1.0 release.

Following the release of Spring Roo 1.1.0. JAXenter caught up with lead
Ben Alex, to find out what’s new in this release, and how the
Spring Roo and Google Web Toolkit collaboration is shaping up.

JAXenter: What are the benefits of incremental
reverse engineering, as introduced in Spring Roo 1.1.0?

Ben Alex: Traditional JPA reverse engineering
tools are designed to introspect a database schema and produce a
Java application tier once. Spring Roo’s incremental database
reverse engineering feature differs because it has been designed to
enable developers to repeatedly re-introspect a database schema and
update their Java application. For example, consider if a column or
table has been dropped from the database (or renamed). With Roo the
re-introspection process would discover this and helpfully report
errors in the Java tier wherever the now-missing field or entity
was referenced. In simple terms, incremental database reverse
engineering ensures Java type safety and easy application
maintenance even if the database schema is constantly evolving.

Just as importantly, Roo’s incremental reverse engineering is
implemented using the same unique design philosophy as the rest of
Roo. This means very fast application delivery, clutter-free .java
source files, extensive usability features in the shell (such as
tab completion and hinting) and so on.

JAXenter: How has the Spring MVC support been
enhanced for this release?

Ben Alex: Spring MVC has been supported since
Spring Roo 1.0, and we’ve received extensive community feedback on
how to make this even more useful. One major area of improvement
related to the JSPX view files that Roo manages. In Roo 1.1, a
developer can now edit any part of a JSPX file and Roo will
automatically detect those edits and transparently merge any
required changes around them. This is useful if a developer wants
to customize the appearance of a view but would still like Roo to
assist by adding or removing fields as they change in the
underlying entity etc. We now also use developer-customizable tag
libraries to simplify application-wide view changes, plus have
dramatically reduced the size of JSPX files. For example, a Roo 1.0
JSPX file of 200 lines is now just 12 lines in Roo 1.1 thanks to
the new tag libraries.

There have also been other changes. Localization bundles can now
be delivered via third-party Roo add-ons. We now also offer
automatic JSON REST endpoints, plus can embed content from 16
social media sites (like YouTube, Flickr, Picasa, Google Maps,
Twitter etc) with a single Roo command.

JAXenter: How has the interoperability between
Spring Roo and Google Web Toolkit, been enhanced in this

Ben Alex: New to Spring Roo 1.1 is GWT support.
This major new feature follows nearly a year of close collaboration
between the Roo and GWT teams. Many new features have been added to
GWT 2.1 to simplify enterprise application development, such as
cell widgets, an MVP framework, request factory and so on. The Roo
1.1 release not only supports these new features, but makes it
possible to build a new application in minutes that use a Spring
backend and a GWT front-end. The Spring backend offers the same
architecture as a normal Roo application, so the millions of
developers familiar with Spring will feel right at home. The GWT
front-end reflects the best practice recommendations of the GWT
team and incorporates requirements such as IoC, a latency and
bandwidth-optimized remoting architecture, mobile client support
and usage of the new architectural features added to GWT 2.1.

The GWT and Roo teams continue to collaborate to make the GWT
support even better. We’re also working with Google App Engine
(GAE) engineers, with GAE support also added to Roo 1.1.

JAXenter: What benefits has the transition to
OSGi, brought to this release?

Ben Alex: An internal change we made in Spring
Roo 1.1 was shifting to an OSGi foundation. This is transparent to
end users, but enabled us to address important requirements so that
third-party add-ons can be easily developed, published and
distributed to Roo installations.

With Roo 1.1 developers can now produce an add-on scaffold in
just one command. With one additional command the new add-on will
compile and publish to a Google Code-hosted project (although you
can host the add-on anywhere desired). The deployment process also
updates the all-important OSGi Bundle Repository (OBR) index file.
We also have a “RooBot” server which can optionally index add-ons
listed in public OBR files. This makes them easier to locate via
automated features built into the Roo client, such as suggesting
uninstalled add-ons in response to user commands, plus normal
search-related commands.

We’re pleased with OSGi because it has enabled us to deliver a
decentralized and secure modularity model. Roo add-ons can be
easily created, hosted anywhere, don’t need to be centrally
indexed, and will only install if a user trusts the add-on
developer. All dependency resolution and security management is
underpinned by mature technologies such as OBR and PGP, ensuring
both add-on developers and end-users enjoy a proven and scalable
approach to long-term add-on requirements.

comments powered by Disqus