The JVM RAD/DSL arena seems a bit crowed these days with Scala, Groovy/Grails, and several other JVM specific languages, not to mention competitors such as Ruby/Rails and Python/Django. What is Spring Roo's place in this ecosystem? It seems that Groovy/Grails and Spring could potentially cannibalize each other, so what is Spring Roo's place in this ecosystem and how does Roo Team plan to help Spring Roo gain more traction? Also, what can Spring Roo do to get beyond the perception that it's good for prototyping, but not for production?
I think Roo has a role to play for getting apps built rapidly, and I don't think there is a down side to leaving it in your project, as long as you use it to the level that makes sense. That said, the big thorn IMO is the web tier, if you don't like the current approach. It's not bad, it's just not universal and spare enough to make it a slam-dunk to adopt for every project.
I also think jspx is not as flexible as jsp for the every day developer. I think they really need to make either one an option. Also forcing developers to go to Tiles is a bit of a strong choice so I think having a sitemesh option makes sense (or pluggable view layers).
Grails has its place. I see a number of shops starting up projects in Grails because of the productivity gains, and because they want to stay close to Spring and Java, but not work in Java itself all day. Sometimes they chase tails around dynamic programming issues instead (why isn't this Groovy code evaluating) but there are definite advantages for the Grails (or even Rails) developers these days.
Roo really needs a community of developers to surround it and submit add-ons, JIRA tickets, and vote on issues. We have to get off of our collective rears a bit and give it a jumpstart. I think the Roo team would embrace that, and would take our suggestions seriously. Also, the Roo project needs a decent vetting place for add-ons too, like the Grails grails.org/plugins URL. So far it's not happened, but I think it needs to.
So, to sum it up, we need to build community, press for improvements, and submit new add-ons / patches to really get it growing. No open source development platform / tool grows just because the original team works on it. It takes more than that.
I see a pattern in my replies. Always 2 of them...
Also, I've been in touch with the development team many times, and they are really interested in reaching out and want honest, sincere feedback from users. I think you'll see more on Roo from the team now that Roo has matured a bit. I really like the platform for developer productivity it exposes and I really think it can go places.
Thanks for the reply Ken. I like Roo as well and I do see potential for it, but there are some aspects of it that makes me think that it's not quite ready for prime time (i.e. can I take a project in Spring Roo beyond creating prototypes). The rigidity on the web tier is a tough sell. I am a server-side developer for the most part, but what drew me to Spring Roo was the possibility of putting up JEE/Spring based applications quickly. Part of the reason I enjoy server side development vs. web development is the web just adds more stuff to configure and deal with. A tool like Spring Roo has the potential to eliminate a lot of the config nightmare that goes along with JEE development. However Roo seems kind of rigid on the web tier. Spring based tools are renowned for their flexibility/adaptability. The Spring Roo project needs to make that web tier more flexible to really have a fighting chance against Grails and Rails.
I have played around with Roo and I think it's pretty cool, but my concern is building something with Roo is having to integrate it into a current Spring project. There seems to be a fair amount fo code removal you have to do. It's as if all of the work that Roo saved gets wasted because you have to go back and retro fit Roo into what you have already built. It seems to me that if Roo wants to really make an impact they have to make the web tier as flexible as possible. This is where a majority of potential Roo developers will come from, and probably the tier that needs the most flexibility. Furthermore, developers should need to remove only a minimal amount of code to make it fit a current Spring project. Right now Spring Roo seems fine if you are starting from scratch, but if you have a current Spring project, integrating Roo may be more work than a developer may want. And most development is maintenance and maybe upgrades versus start from scratch development.
I share your concerns. I agree, we should not be removing from an app to fit what we want to it, the starting point should be universal and spare. Something it takes 3 minutes to replace. Not a fully realized web tier with selections made for us.
Please voice these concerns on the SpringSource Roo forum. I think the more that hear that the current state is holding them back on some of these issues, we could have a positive impact on 1.3 planning.
I tried to register for Spring's Roo Forum. It was a complete waste of time. I registered, I confirmed my account and I was still told my login was incorrect after 5 attempts. I felt like I was applying for a home loan instead of registering for a developer forum. If that forum is indicative of how Spring Roo handles it's users, then I'm not so sure I want to post on their site. It was a complete pain, I gave up.
I have been a user for a long time, so I can't tell you what's going on there.
I wonder if they're having server problems... That stinks. Send me a message privately and I can forward it to someone at SpringSource who can look at it. You can also hit up Josh Long, who is the developer advocate at SpringSource and I can assure you if he knew there were registration problems he'd get it solved. I can get him on it right now if you request it.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com