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 thingsIt 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 awayIt is perceived as being a replacement / substitute for Grails, which I would not yet agree withIn 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 itThe 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.
Best,
Ken
1
