Ben Alex: ‘The GWT and Roo teams continue to collaborate to make the GWT support even better.’
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 release?
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.