Monthly Archives: June 2010

Spring Roo Rocks!

OK, that overstates it a bit for me, but consider it kind of a make-up call for my overstating my previous objections.  However, a couple things I think are awesome:

  • After posting about Roo sucking, Ben Alex, founder and lead for the Roo project himself, got back to me to address some of my concerns.
  • I thought there were some “not ready for prime-time” problems and some fundamental problems.  Ben, who is way smarter than me, took the time to explain how some of my “fundamental” problems had potential solutions.  Now, these things aren’t solved yet, but they’re on the roadmap and they’re not insurmountable as I first thought.

I am very impressed that the project lead cares enough about gripes from unknown developers out here that he took the time to respond personally.  That bumps the whole project up in my book.  It’s still not in a state where I can use it for myself, so maybe this post should be “Ben Alex Rocks!”, but it had exciting potential to really increase productivity before I tried to use and it has exciting potential again.  I’ll be watching carefully.

Spring Roo Sucks!

I’ve been trying out Spring Roo and the first pass was very impressive and exciting. I created a domain model with persistence lickety-split with integration tests to boot! Seriously, like 30 minutes.

Then I created a default web application – neato! It’s certainly not the web application I would deliver as final, but there’s a lot set up for you there and it worked.

Then I went and started changing my entities – adding fields, overriding toString, etc… works great! OK, I didn’t like my package structure because I had all my domain objects in the same package. Let’s create some new packages and move stuff around using Eclipse refactoring… oops! Now there are some errors in my AspectJ configuration stuff. Too bad I haven’t really learned AspectJ except the broad strokes, so I don’t really know what’s going on. I manage to find a configuration file with references to the old classes in their old packages. I remove those references and things are working again… not too bad. The honeymoon isn’t over but we’re packing our bags to check out of the hotel.

Then I decided I wanted to try GWT instead of Spring MVC. Both are supported, so it should be easy, right? Well, guess again.

I couldn’t figure out (at least in a short amount of time) how to undo the Spring MVC stuff. Well, that shouldn’t be that big a deal. Since most of the code in the domain layer is auto-generated anyway, I’ll just create a new project and copy the relevant entity files over and start again from there. That was troublesome for reasons I can’t explain, probably my fault, but I got through it. Now, before I run ‘setup gwt’ I decide I don’t want to have this back out problem again, so I’ll put all of my domain stuff in a maven module. Then I can create my gwt module and just add the dependency, right? No, that’s not possible, since all the Roo annotations are only available at compile time, they’re not in the bytecode, so the gwt stuff has to be in the same maven module.

So punt on that idea and just run ‘setup gwt’ in the same project. Oops – some of my entities have one to many relationships represented by a Set, but that’s not supported yet so I’m getting compile errors. That may be just because it’s an early release version, but it’s a pretty big problem.

OK, so GWT (and probably Spring MVC) are not ready for prime time and maybe never will be for multi-module projects, but it’s still pretty useful for the domain model, right. I’ll just create a module for my domain (as long as your domain is in one module) and just hand-code GWT like we all had to do before Roo. Well, no. It turns out Roo is not very interested in supporting multi-module projects at all, including just specifying a parent in the pom.

In summary:

  • Roo generates “stock-standard Java”, but it turns out that, like most automated code generation tools before it, it’s very obtuse and easy to edit it in ways that mess up the round-tripping.
  • Roo only good (if it’s good at all) for single, monolithic maven projects.
  • Roo + GWT is only good for simple demos.
  • It’s going to make me look bad because after trying my initial toy project, I promised a larger project in a short amount of time that is going to be impossible to deliver.
  • It made me feel stupid because I should have known better.  There are no free rides.  (How many times must I relearn this lesson?)
  • Roo is only three letters and makes a bad Twitter hashtag.
  • Roo is a stupid name.

Update 12/14/10:

This does not represent my full opinion on the subject as I have related subsequent posts on the subject here and here.  The tentative conclusion I have made is that I still can’t use it, but that, hypothetically, it could be used to bootstrap a project, then pull all the Roo annotations out.  For that to be worthwhile, you (and those who contribute to your code) would need to know your way around AspectJ and you would need to have a pretty good idea of your application up front.  If you used it just for a bare bones toy version of the application, I’m not sure the effort of pulling the annotations out will make up for the requirement to use exactly the techniques Roo picked for you in the first place.