This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Having used Ruby on Rails and Spring Roo both, I think view customization in Rails is relatively straight forward compared to that in Roo, at least for a person who might be looking at both frameworks for the first time.
I am interested to hear though other thoughts on it as well
Jeanne Boyarsky wrote:I asked a Ken a variant of this in person, but I liked his answer. So asking here to get him to share it with others.
I hope I represent it the same way this time ;) Off the cuff and into the ether...
Let's see. I think that Ruby on Rails came at just the right time and served a need for the community of PHP, Ruby and Python developers out there who hate compiled languages. Java EE people who hadn't used Spring, or even who had, may have gotten involved in smaller scale projects that Rails fit perfectly - get it out quickly, with fast changes, and a small development team. Java people who jumped on the bandwagon thought that it was awesome - let's face it, if you spent your whole life typing 'mvn package jetty:run' and someone comes over and shows you how you can just iterate while the server is running, you'd probably be convinced.
On the Java front, we had an answer to dynamic languages, and a pretty good one too, Groovy. Groovy begat Grails, and Grails was a runaway hit in our circles - a viable alternative with mostly the same goals - yes, you did have to restart (until Grails 2) to get domain changes going, yes, it's girded on top of Spring/Spring MVC/Hibernate, and so it is a DSL against known frameworks rather than a ground-up implementation, but the thing works. And works well for most applications.
Around the same time Grails was building steam, the Java team at SpringSource, led by Ben Alex, created Roo. It attempted to accelerate application development, but by using what they already had - Spring, JPA, Spring MVC, Tiles, etc... It was a valid decision. It kept the development IN Spring, and it kept it IN Java. Enterprises would then have the choice of a dynamic language platform written around a DSL -vs- a tool that helped keep the C.R.A.P (Completely Redundant And Painful, like that?) from taking over a project, and extensible by add-ons.
The reasons I think Roo hasn't caught on as much are:
It is written in Java. Zzzzz for many developers, but it girds the infrastructure of many, many things
It isn't cool like a DSL - rather, it relies on the coolness of the existing frameworks (hint, Spring Data JPA for example)
It came late to the party - Groovy/Grails was a great follow-up to Rails, but being third isn't always the way to get to the top right away
It is perceived as being a replacement / substitute for Grails, which I would not yet agree with
In my mind, it's still early, since it has evolved to a much better tool in 1.2.x, and is getting to become viable for multi-maven projects, but I think it needed to mature before it was able to really be taken seriously in the places that would use it
The add-on community doesn't yet exist to any big depth, at least in terms of public add-ons. And the add-on API has broken between revisions a bit, causing agita for add-on developers. I think that will start to change going forward.
Jeanne, I hope I answered the question well enough... I believe Roo 1.3 will be a strong release, in that we will hopefully have not only a more solid add-on API, but the ability to customize and tailor the application platform and the benefit of stability fixes etc... The team is committed to the tool, are very interested in what the community wants, will accept patches for fixes, etc...
Also, look at some of the things you can use Roo for, such as writing your own productivity add-ons, dealing with JavaBean, JSON, and other features for just regular old beans, and the like, and you needn't use all of it to get benefit from its productivity. In a way, it's kind of a blank slate that you can apply your abstractions to - think of the Maven archetypes for example, and then think of live archetype commands that can alter an existing program, generate AspectJ ITDs, even restructure things, and you get the idea.
Agreed Mark. I see the web mvc teir as optional and am hoping someone comes up with another one that is more flexible, lightweight and less opinionated. No JS framework plus adding add-ons for that, like in Grails, makes more sense to me for most applications. I also don't really need bi-directional field sync for most apps, if I have to live with JSPX files as a consequence.
I had shared that feedback with the Roo team but more discussion should be had around the web tier... It may be a JiRA suggestion to file to request a cutting apart of the mvc add-on into a few more pluggable items - view strategy, template strategy, client js framework, mapping strategy (entities or dtos), etc.
author & internet detective
Jeanne Boyarsky wrote:Ken,
Yes good answer. It is more thought out than the in person one, but the spirit is the same. And I can't complain a "surprise - lets ask Ken questions at lunch" answer wasn't planned out!
Must be all those years playing jazz drums. I actually enjoy that kind of thing...