Is Roo alive?

[eruiz]

Anyone is maintaining Roo? At Jira, the last change was done in 25/Feb/13

I know Roo is an open source project and Alan is not in VMWare, but the community need a agile way to contribute to Roo, so our pull request should be attended.

Thanks

[krimple]

I get the feeling we'll have to wait until the Pivotal initiative is sorted out to see what Roo has in store for the future. I agree, I think we should have a way to contribute to the project to move it forward and clarification is needed. +1 on your request for information from VMware on Roo development support today and in future.

Ken

[delgad9]

We might be watching the end of an era unfolding...

Without Rod Johnson, Spring source has become a just-integration-no-innovation shop.

Without innovation it will really be hard to prevail in a very-very competitive market; specially when your main differentiator -IOC/DI- has been assimilated by your main competitor.


I hope I am wrong in this one.

B. Roogards
jD

[FreeCoffee]

Ken,

I'd like to get your thoughts on the future of spring/roo. How about a nice blog post? I've built a pretty nice application on spring with roo as a starting point, and extjs as a front end. Roo has helped flatten the learning curve as I've moved from .Net to Java. I think roo it's very close to being an amazing project. It seems to me that there are a few simple things that could be added to make the code-generated user interfaces more useful out of the box. I wish a strong team would get behind one of the UI plugins and create some more impressive demos.

[krimple]

Comment appreciated, FreeCoffee.

Yes, I have plenty of thoughts about where Roo is now and what it could do in the future. Writing a book for two years tends to do that to a person. I have a vested interest (altruism, the book, future royalties) in seeing Roo not die, so I 110% agree with you. I am hopeful that we see an opening up of the project again quickly so it doesn't die due to being out of mind too long. It really has some great parts, especially the shell mixed with a pluggable add-on architecture.

I'm so busy with wrapping up our Emerging Tech conference this week that I just can't add the blog post. I'll elaborate here since it's probably the best place to get my feedback down.

Where it currently breaks down for me is the web tier. I feel Grails and Rails got it right - generators are for beginners and getting started, but get it out of my way if I'm writing my own application. Also, make UI parts pluggable, and don't make too many assumptions. I think it was great for a 1.0 project's web app tier, but I almost always gut it and do my own thing. I had suggested this feedback to the team in the middle of writing the book, but I think it was put in the "when we get to the next big version" category.

JSPX is an unfortunate choice for day-to-day development, and feels quite limiting and full of too much ceremony. I would like to see different page parsers - even using Velocity, HAML or Thymeleaf. Spring is built for that, and most of us honestly don't need the bi-directional 'keep the page in sync with the model' choice. It's nice as a feature, but if it makes development tedious, we'd all probably drop it for a push only get-it-started template in our favorite view language.

Also, the reliance on Dojo is an artifact of 2008/2009 web programming, and not relevant anymore. We should have the ability to choose the client-side toolkits we want, and to go to a single page web application if we feel we should. AngularJS is my current passion right now, and Roo doesn't easily integrate with it - you have to behead and adjust a lot of things to get it set up. Not that it's a big deal, but it should be thought of going forward.

The localization templates are a good idea, but the syntax is very long for what it should be - there needs to be a way to flatten it and remove it outright if I never wanted it in the first place or wasn't scaffolding. So bottom line, the web mvc add-on needs to have differing levels, such as:

web mvc setup // just give me <mvc:annotation-driven /> with some good assumptions, JSON/XML converter support, etc.
web mvc install-theme
web mvc install-localization
web mvc install-client-toolkit --type dojo|yui|etc...
web mvc install-template-engine --type jsp|jspx|velocity|thymeleaf|haml|etc

Also, we need a command for push-in refactoring - sewing up and leaving Roo at the door. Using the IDE isn't enough, and many want to use other IDEs for an ultimately non-AspectJ architecture. You can't use IntelliJ right now because the team there hasn't implemented the 'declare parents' feature - which was introduced in Roo 1.2.3 I believe (maybe 1.2.2) so we need to keep bugging them on that score (vote up http://youtrack.jetbrains.com/issue/IDEA-59138). And once pushed in, we should be able to access the app code from NetBeans or other IDEs as well.

Roo is great for starting up projects, but it would be more useful if we could keep it for those who want it well up into the web tier, without having to resort to hacking it down and working around the current web addon to do so.

I am hopeful that the dev team adds external committers and helps us establish a way to install add-ons from the internet easily. The big problem is that if nobody sponsors or keeps the add-on repo running, we won't have a place to search for and then add add-ons.

Further, I'd like to suggest that if Pivotal wants to sponsor Roo development as an open source partnership, but not engage in it as a key activity, they could commit to providing a part-time 'caretaker'. This person could make sure we have server space on AWS, Cloud Foundry or another place for whatever future online resources we need to manage add-ons, and that caretaker could appoint committers who could ultimately be in charge and push builds. Or they could donate it to Apache or Eclipse and see what happens.

Let's see what ideas Pivotal comes up with. I don't want to see push requests go ignored, and I'd certainly be more inclined to help with the development now that the book is over, if I knew we were on a path to having releases that we need to keeping Roo moving forward.

I hope this feedback is taken in a positive light, and helps VMware/Pivotal.

[snowch]

Have any times scales been announced for pivotal decisions to be communicated?