Spring Aiming to Bring Grails-like Productivity to GWT Application Development With Roo

Posted by Mario Gray on Jul 27, 2010

Sections

Development

Topics

Web Frameworks ,

Java

Tags

SpringSource Tool Suite ,

GWT ,

SpringSource ,

Spring Roo

In May, VMware and Google announced a collaboration between the engineers of VMware's Spring Roo framework and Google's GWT Java-to-JavaScript compiler. The collaboration aims to deliver the productivity gains of Spring Roo to the Java-based GWT rich Internet application framework.

Spring Roo, led by SpringSource's Ben Alex, is a light-weight rapid application development stack that attempts to bring the rapid feedback and productivity features enjoyed by developers using other full-stack solutions (e.g. Ruby on Rails and Groovy on Grails) to the Java developer community. It provides a shell that generates and manages the life-cycle of classes using a simple command language to describe project setup, entities, controllers, and much more. It provides a set of source-code-retention-level annotations that enable developers to "opt-in" to various Spring Roo services for the classes they annotate.

Spring Roo also lets developers generate a domain layer using the shell, but keep in mind the approach departs from the traditional Java Enterprise method of employing DAOs in favor of the much discussed preference toward the Entity Manager pattern. From the Spring Roo reference:

Most traditional Java enterprise applications will have a DAO layer, services layer, domain layer and controller layer. In a typical Roo application you'll only use an entity layer (which is similar to a domain layer) and a web layer. ... a services layer might be added if your application requires it, although a DAO layer is extremely rarely added

An application may be taken all the way through the creation of a Spring-MVC-, or GWT-MVP-based CRUD scaffolding application.

Google Web Toolkit (GWT) is a Java-to-JavaScript compiler that lets developers program using Java IDEs and idioms in their code. The final "compiled" application is indeed JavaScript, and can be used to build cross-browser, interactive web applications. GWT includes the Chrome extension Speed Tracer, a tool that enables client side application profiling and debugging. Speed Tracer includes server-side profiling, although the support is limited to Google App Engine (GAE), and SpringSource tc Server Developer Edition. As the GWT project site states:

With this integration, you'll be able to view metrics for database calls, memcache hits, resources fetches, as well as other server-side service calls.

The new collaboration with Google allows the developer to extend the application with GWT, and enables deployment to GAE with DataNucleus persistence support. Spring Roo - in the background - automates the project lifecycle; from wiring together GWT MVP views to setting up the GWT compiler, configuring domain persistence, dependencies with Maven, and more.

Spring Roo provides a command to generate JUnit integration test cases of the domain layer. A set of test cases - built on the Spring integration testing infrastructure - are produced to verify that common JPA operations such as CRUD, all work. Additionally, Spring Roo relies on the Selenium tool to create automated tests for each of the project's web controllers. To enable web-tier testing, Maven starts a Tomcat server instance. Spring Roo then deploys the final test web-application for developer verification.

To support round-tripping code generation in the background, Spring Roo relies on AspectJ Inter-type declarations (ITDs). An ITD is an aspect described in a Java-like syntax that is woven into the Java classes at compile time. Spring Roo manages the ITDs, reacting to changes in the Java classes that they belong to. For example: given a class annotated with @RooToString, Spring Roo might generate, or update, a toString() method in an aspect that enumerates all the variables in the class. This method gets compiled into the final .class file, in effect freeing the developer from having to manually write that code.

Setting up an IDE such as Eclipse, or IntelliJ to acknowledge code generated with ROO will require the plugin which provides the AspectJ Development Toolkit (ADJT). This will enable support for code-completion using AspectJ aspect artifacts within the development environment. SpringSource provides a free (as in beer) Eclipse-based distribution called SpringSource Tool Suite (STS) that includes a full host of plugins ideal for Spring Roo development (like the m2eclipse plugin). The IDE is a useful, if unnecessary, luxury, however as all commands are still executed at the ROO shell.

An example application was put together by Christian Dupuis with instructions on his blog at SpringSource. His post goes through all of the steps to configure STS, generate a project using ROO, and deploy a basic GWT app to GAE. Whilst still in the early stages of development the STS with GWT integration shows a lot of promise.

1. Back to top

   Tried it and it is not ready for prime time!

   by Mark Stang

   M2 says it all. If you watch the video closely, you will see there is a "gap" where they stop using the tool and do stuff manually. They don't tell you what they are doing, there isn't any documentation and the included scripts generate code that doesn't work! Very shoddy release, wait for them actually finish the code.
   
   And Google was in on it! Watch "Ray's" talk, you will see a lot of hand waving and then he points to Roo.
   
   The Roo people get up on the Google stage and make it seem it is ready to go, eh, not so much!

   Reply

2. Back to top

   Re: Tried it and it is not ready for prime time!

   by Dorel Vaida

   Definitely my opinion too. I was a huge fan of Roo - GWT integration, I am still a huge fan of the idea, but I really don't like the approach Roo has taken in GWT's case. Especially usage of Ray Ryan's MVP approach is arguable, at least to me. It seems to be too much of an architectural overhead for the bulk of the applications out there. Not everybody develops Google Adwords. Anyways my only option (I have also tried others) is to wait and see what a final version of this addon will hold. For now, it's not up to it's promises. Neither the general idea nor the execution.
   
   Regardless of the GWT addon, my opinion is that Roo is one of Java's latest bright inovations, a yet to be uncovered gem.

   Reply

3. Back to top

   Re: Tried it and it is not ready for prime time!

   by Bart Cowell

   Roo has potential, but it's far from ready for prime time. The Google I/O presentation was very deceiving about the maturity, and you must make too many compromises when using Roo. I think Rod Johnson said that Spring Roo is an opinionated tool. In my opinion it's a bit too opinionated.

   Reply

4. Back to top

   Re: Tried it and it is not ready for prime time!

   by Ben Alex

   Thanks for posting this article on Spring Roo.
   
   It's important to remember the GWT support is part of the Roo 1.1.0 version, which is presently only in milestone form. In both of my Roo 1.1.0 blog announcements I noted milestones are not intended for production use. We release milestones to show you our progress towards the next major release (as per normal iterative development methodologies) and collect feedback, bug reports and enhancements.
   
   Spring Roo's GWT support is building on many new features in GWT 2.1, such as the RequestFactory. GWT 2.1 is also at milestone 2 at present, and both the Roo and GWT teams are expecting a further four releases before Roo 1.1 and GWT 2.1 are at general availability (GA) quality. The GWT and Roo teams are planning their next releases (to be tagged milestone 3) in mid-August and are working very closely together to ensure the eventual experience is highly compelling.
   
   I'll close by observing that the GWT support is a very ambitious piece of work. The RequestFactory feature for example significantly revisits remoting and data binding in GWT so that it works well on mobile clients and desktop clients, plus makes it easy to deliver statically-typed, code-assist friendly, payload-optimized, latency-minimized, UiBinder-compatible views. It takes a few months to get something that ambitious complete. People can still use GWT's existing remoting and REST support if they need something more quickly, but the wait will definitely be worth it.
   
   Ben Alex
   Project Lead, Spring Roo

   Reply

5. Back to top

   Re: Tried it and it is not ready for prime time!

   by Dorel Vaida

   Thanks for completing the picture Ben ! I was somehow troubled to see Roo's pace slowing down a bit but what you say actually makes sense. Is there any way this process can be more transparent ? Is there a place where the joint effort Roo/GWT can be monitored a bit more closely ?
   
   Thanks,
   Dorel

   Reply

6. Back to top

   Re: Tried it and it is not ready for prime time!

   by Ben Alex

   Hi Dorel
   
   We've already closed some 400 issues towards Spring Roo 1.1.0. There are many new major features coming to 1.1.0 including GWT support, Google App Engine support, significant Spring MVC enhancements (JSPs that used to take 130 lines in Roo 1.0 now take 12 lines), major new add-on discovery and distribution infrastructure (including shifting all of Roo and its add-ons to an OSGi foundation with SCR and OBR), and the most popular feature request to date - incremental database reverse engineering. There are lots of other smaller features, too, like automatic Git commits, Op4J, web MVC embedding, automatic serializable support, add-on development tools and many others.
   
   I think the community will really enjoy Spring Roo 1.1.0. We're on-track to deliver it in mid-October 2010. In terms of transparency, our work with Google is tracked publicly via the Roo Jira issue tracker, public Git repositories and public releases every 4-6 weeks. The Roo release schedule is published at tinyurl.com/rooroadmap. We're also very happy to answer queries, so you need only send me an email or post a forum message if you're curious about something.
   
   Cheers
   Ben

   Reply

• Older >