Comments on: Why Spring Roo is not my thing

By: Stephane

Stephane — Wed, 20 Jan 2010 14:00:41 +0000

What would be nice is to be able to add to an application, some lean libraries that focus on one thing each.
I would like to be able to create an application with a tool like Roo, only to create it fast, then forget about Roo and code it further in Spring. I would then use a gorm.jar helper library to give me dynamic finders, and a coc.jar helper library to give me conversion over configuration so as to allow me not to explicitly wire up my application controllers with annotations (no Spring autowiring). And of course, all of this available on the command line. Coding with an IDE is a pain in the… neck. The name resolution offered by Roo on the command line is superb ! This name resolution is enough for me to ditch the IDE. I’d say Roo is one step done right. One more and we can dance !

By: Jonathan Woods

Jonathan Woods — Fri, 15 Jan 2010 10:31:57 +0000

For people not seeing AspectJ tooling working: don’t forget that your IDE needs to know aspects are involved. I’m using Eclipse, and found that using perform eclipse in the Roo shell gave the Eclipse project its AspectJ nature, and then lo! code completion etc all worked fine.

By: Ken Rimple

Ken Rimple — Fri, 11 Dec 2009 14:30:14 +0000

Nope, same as before. As long as you don’t try to use ITD methods (like entity weaved methods such as find, etc) from java classes, the compiler doesn’t complain. But then that means writing real code with the tool will generate compiler errors. So until the AspectJ plugin for IntelliJ has ITD support we’re where we were.

By: Ken Rimple

Ken Rimple — Fri, 11 Dec 2009 00:48:00 +0000

I am the cause of that confusion. Didn’t realize what I wrote in that blog entry and have to go back and correct it.

That entry that says that IntelliJ ‘works pretty well’ with Roo was mine – at the time I was experimenting with the framework and seeing what could edit the files. The problem I had was that I got build errors, and it didn’t support ITDs directly. I was building using Maven and using IntelliJ as a text editor at that point.

I am testing Roo RC3 and the newly released IntelliJ 9.0. It seems to be working (at least not giving me errors on the annotations). I’m going to mess with it and post an updated blog entry.

Sorry for creating confusion.

By: Stephane

Stephane — Fri, 04 Dec 2009 14:01:42 +0000

Thanks to the Roo team for their command line interface. I think the command line is the only robust way to handle code.

Eclipse is welcomed to the code production process when it is used with Maven.

I too am not a fan of annotations. They look like they are not part of the code. As long as they can stay out of my way and of my sight I’m fine.

We may need a good Oreilly book on Spring Roo to really see what it’s got for a punch.

By: jettro

jettro — Sat, 07 Nov 2009 09:25:19 +0000

I am sure it is not windows, but a mindset. If you only want to use an ide that is your choice. I know a lot of people that are much faster using command line and vim than others using eclipse or whatever IDE. I like to combine them to get best of both worlds.

By: Roy Mustang

Roy Mustang — Sat, 07 Nov 2009 01:38:55 +0000

@Manoo Tige

Your biggest problem is that your programming on windows. Unless you`re using Visual Studio and specially if your doing web development, stick to linux or mac.

Windows console, including PowerShell absolutely sucks.

By: Manoo Tige

Manoo Tige — Thu, 22 Oct 2009 16:30:20 +0000

Why do we have to use command level tools? Tabs and auto-complete help would have been ok olden days.. why now? Everywhere we see GUI and mouse and all of a sudden, surprised to see this….

Not that I am unfamiliar with c:\ prompt… I am one of the very few who still use all CP/M commands under Vista cmd.

This ROO is might be good learning tool for people to start with,,, In real life, in large projects, I do not see any role for this! I may be wrong….

By: Rodrigo

Rodrigo — Wed, 12 Aug 2009 16:41:20 +0000

Coding in Groovy is much more productive than coding Java, and that is why Grails is more productive than pure Java. Roo, such as Grails, tries to imitate the best practices of Ruby on Rails and, although Groovy is not far behind Ruby, Grails nor Roo can actually compete with Ruby on Rails. Roo even tries to imitate the name (Roo ~ RoR). What does Roo stand for? If you really want to be extremely productive, try Rails instead of Grails or Roo.

By: Ben Alex

Ben Alex — Wed, 22 Jul 2009 03:52:19 +0000

@Jettro, thanks for your feedback.

1. JSPs customization. As Stefan mentioned, we want to do the round-trip support for JSPs properly and ROO-8 is capturing requirements on this issue.

2. Support for compositions. As Stefan mentioned, we already have support for this.

3. Use of aspects. We believe the compilation unit separation is one of the most fundamental innovations in Roo, and I blogged about this in depth at http://blog.springsource.com/2009/06/18/roo-part-3/. It’s worth noting that standard Eclipse plus all Eclipse-derived IDEs already enjoy first-rate AspectJ support and as such automatically enjoy first-rate Roo compatibility. As an aside, Roo works entirely at the command line and doesn’t even need an IDE (eg I routinely test my Roo changes on projects at the CLI and don’t even import them into Eclipse as it’s unnecessary given I can run easily JUnit, Selenium, Tomcat etc all from the CLI). I also discussed the issue of IDE compatibility in some depth in the comments section of my blog entry, so rather than repeat it all again here I’ll link to that discussion: http://blog.springsource.com/2009/06/18/roo-part-3/#comment-167388

4. Finders sophistication. As Stefan mentioned, we already have support for this.

@Erik, both Grails and Roo represent SpringSource-endorsed and SpringSource-sponsored approaches to productively building applications on top of top of the proven Spring family of projects. We have both Grails and Roo because static languages (Java) and dynamic languages (Groovy) are different programming paradigms that each have their own unique advantages and disadvantages, and we wanted to offer a compelling productivity solution for everyone – irrespective of their preferred programming paradigm.

Best regards

Ben Alex
Project Lead, Spring Roo
Principal Software Engineer, SpringSource