Ben Alex

I wanted to share some details of Spring Roo in light of specifics
raised by Skyway's blog entry.

First of all I'd to help readers of the Skyway blog be able to read
about Roo for themselves, download a copy and give it a try. Skyway's
blog didn't include a link, so I will do so here:
http://www.springframework.org/roo and also
http://blog.springsource.com/2009/05/01/roo-part-1/.

Moving onto the technical discussion, Roo does not use Eclipse EMF nor
Eclipse technologies. Whilst SpringSource is fortuitous to employ some
significantly talented Eclipse engineers (who lead popular technologies
like SpringSource Tool Suite (STS), Spring IDE and AJDT), we carefully
considered the various engineering issues and elected to build Roo
outside Eclipse. The benefits of this decision include a <3 Mb download
(not a 100+ Mb download!), compatibility with any IDE a person may wish
to use (not just Eclipse), the ability to script the tool, the
significant level of expressive conciseness and productivity possible
through a text-based UI, a very lightweight and flexible add-on model,
plus numerous other benefits.

It's interesting that every modern mainstream RAD framework uses
text-based UI paradigms (not IDEs like Eclipse). Of course, Roo has full
Eclipse-based IDE support in the now-free STS product, enabling people
who prefer to stay solely in their IDE to do so and still enjoy a truly
first-class experience. The key point is Roo gives you the flexibility
to use just the IDE, just the text-based UI, or both concurrently.

A more important point concerns the issues associated with modern code
generators. I will write an entire blog entry on this topic soon, but in
the meantime will simply observe that existing code generators generally
have some limitations in the way that they operate. For example,
existing code generators emit code in the same compilation units as they
expect a user to maintain, or emit special "do not touch" compilation
units that must be maintained by the code generator indefinitely. Some
code generators prevent the user from editing Java whenever they want
to, or need to specially mark certain members as "edited". Other times
code generators insist on being part of a build script, or require you
to maintain special plugins within your IDE. Some have a questionable
debugging story, limited SCM integration options, lack flexibility for
significantly different architectural models plus facilitate an
explosion of verbose, unnecessary and confusing layers that add little
value. Existing code generators also generally have a limited to
non-existent round-trip story, which is fundamentally critical to
sustainable productivity, and some make it very unclear what is really
going on. We took all of this (and more that I'll blog about) into
account when designing Roo, leading to a non-invasive, flexible and
thoughtful model that uses aspects to ensure we can deliver meaningful
compilation unit simplification whilst resolving the issues present in
modern code generators. Aspect-based approaches underpin most modern
Java technology (including Spring), so it's hardly a big surprise that
Roo would also use aspects given their repeatedly-proven mainstream
usefulness.

The layering technique of a separate DAO/repository, services, domain
and controller layer also deserves some reflection. Every modern
mainstream RAD framework places persistence logic within the entity,
which we believe is perfectly sound and pragmatic, especially in this
era when JPA transparent persistence and object graph navigation
undermines most of the initial motivations for dedicated persistence
layers. In relation to services layers, these act as little more than
transaction scripts in most practical usages. These transaction scripts
delegate to so-called domain objects, which themselves are anaemic
DTO-style objects that generally serve little architectural purpose
beyond ORM and MVC form backing usage. This does not represent the
maintainable, encapsulated, efficient OO we all should be striving to
build, and is certainly inconsistent with the definition and motivation
of the patterns purported to being observed.

For the sake of clarity, Roo does let you still write services layers.
In fact if you are observing the actual architectural intention of
services layers, they're a very good idea. I wrote a services layer live
on-stage last week at SpringOne using Roo, so it's not particularly
complicated � you just create a class as you always have. You can also
write an add-on that emits a separate repository layer if you really
believe you simply you must have one. Naturally Roo separates web
controllers into their own layer by default. Whilst mentioning the web
tier, I'll also note there is no incompatibility with Spring Web Flow.
The Spring project team works closely together and naturally ensure all
projects work well together for the benefit of the community, just as we
always have. Indeed Spring Web Flow functionality is going to be one of
the next add-ons we provide out of the box.

Those concerned about layering should also take much comfort from the
fact that Roo automatically delivers its users the
SpringSource-considered best practice for modern enterprise applications
built in the Java programming language. The people designing these best
practices have been using Spring, helping the Spring community,
professionally providing Spring services, speaking at Spring conferences
and leading various Spring projects since as far back as 2003. Every
engineering decision within Roo � and the architecture that Roo
advocates � is underpinned by this significant history of pragmatism,
community feedback, peer review and engineering integrity. We are
pleased to debate in great depth any engineering decision associated
with Roo.

In conclusion Roo brings the best of usability, productivity,
flexibility and quality engineering within reach of enterprise Java
developers everywhere. We solve the numerous problems of traditional
code generation whilst also delivering SpringSource-considered best
practice architecture. Given all of this is freely available in a
lightweight open source project that also includes full IDE integration
with the now-free STS product, we know the community is absolutely going
to love it.