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.

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?)

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.

Comments

Sorry to read your experience with Spring Roo wasn’t as you hoped. It sounded like you started off well, but got into difficulty when some packages were renamed and one thing led to another.

Concerning package renaming, Roo usually handles that well. You mentioned you received “some errors in my AspectJ configuration stuff”. I’m guessing from this that AJDT probably got out of sync with what Roo changed on your file system. Usually a quick refresh and clean will sort it out. I’d be interested to know which configuration file you had to edit to fix things up. It sounds unusual.

Regarding Roo’s GWT support, this is preview quality. As I said in my blog posting announcing Roo 1.1.0.M1, “we’ve now started our journey to full GWT support”. We certainly don’t consider the GWT support completed. The problem you described is because GWT 2.1.M1 doesn’t support relationships in its request factory feature. The GWT and Roo engineers are continuing to actively collaborate and you will see significant improvements over the coming milestone and RC releases.

In relation to multi-project modules, this is a feature request that currently has 41 community votes. We use community voting to help guide what we work on. In the case of Roo 1.1 we are working on some other issues that received more community votes such as database reverse engineering (98 votes), data access persistence pattern flexibility (49 votes), Any/Ivy preliminary work (51 votes) etc.

Concerning Roo’s project name, this has a long history. Again the community voted for their preferred name and “Roo” was the significant winner. You can read a fully history of the name in the Roo reference guide “History” section. Re Twitter, we responded to the significant spam on the #roo hash tag by switching to @SpringRoo for tweets several months ago. We hope this change helps people find relevant tweets.

As I said towards the end of my Roo 1.1.0.M1 blog post, “As a milestone release, Roo 1.1.0.M1 isn’t intended for mission-critical use”. Roo 1.0.2 is the preferred choice if you’d like to build a real application today.

I hope you’ll take another look at Roo 1.1 once we reach a final GA release later this year. If you have any further comments or would like to try to get Roo to work on your existing project, please feel free to send me a direct email and I’ll be happy to assist.

Let’s separate out me real problems with my tongue in cheek ranting. My lashing out at the name was just rant. I don’t believe it is substantive and didn’t believe it at the time that I wrote it – just going off.

The shortcomings on the GWT side can be totally forgiven since it is clearly an MS1 release. I was a little frustrated at being duped into trying it for something approaching a real app, but that’s on me. The demo I saw oversold it’s current capabilities, but on the other hand, of course it did.

Now my real gripes:

Not supporting multi-module projects is a deal-breaker and a bit surprising that it’s not more important to other people, including internal Spring developers. (Is roo itself a single-module project?) It seems that there are some simple things (like supporting a parent in the pom.xml) that could be addressed with enough interest, but it also seems that there are some fundamental difficulties with supporting some of these things because of the fact that the annotations are only in the source. I understand the motivations for that (not needing roo libraries at runtime) but it would make some pretty cool stuff impossible. For example, what if I wanted to have roo build a web scaffold in one module with dependency on a domain model annotated with roo? How would that ever be possible?

A general disenchantment with machine generated code as something that could actually be futzed with by hand. It’s always hard to understand and as far as I can tell, very difficult to make it anything other than fragile. I will say that the AspectJ stuff was pretty close, but the automatically generated pom.xml and other configuration files seem to have all the problems I’ve seen before with automatically generated stuff.

Re multi-project, it is one of the most popular voted issues and is on our roadmap. As mentioned in my earlier post, we are tackling a number of popular community requests in Roo 1.1 already. We could add more to Roo 1.1, but it pushes the GA date further into the future and eventually we need to draw a line in the sand and aim to deliver the stated features well in a predictable period of time.

Multi-project isn’t actually too hard to do but one of the major considerations is it requires more complex abstractions and these in turn move us away from Ant/Ivy support. At present more people are looking for Ant/Ivy than Maven multi-project support. It’s probably possible to deliver both, but some basic Ant/Ivy support to start with lets us get a feel for it.

Concerning the source-level retention of @Roo annotations, there are ways to solve that. For example we could make Roo’s Java parsing and type binding infrastructure walk the source code of related projects. Or alternately add a Roo Maven Plugin to projects so the @Roo annotation metadata can be moved into an XML/JSON file. That way it doesn’t contaminate the user’s .class files yet remains available to Roo. People not requiring multi-project support would be able to do without that metadata file. It’s not particularly difficult to pursue these options, they just need time.

Again I’d like to thank you for sharing your thoughts. Please don’t hesitate to get in touch if I can be of any assistance in the future.

This humble blog is probably not the best place to hope for a response from Ben Alex. I am not his spokesperson (clearly) but I can do my best to clarify. When he says, “alternately add a Roo Maven Plugin to projects so the @Roo annotation metadata can be moved into an XML/JSON file,” he is responding to my comment about how it seemed like Roo itself could never get around source-level retention. He is proposing possible strategy the Roo team could use to overcome this limitation in the future, not a technique a current Roo user could use to solve the problem.

So, how did you solve the main issue?, that is, integrating Spring and GWT. I had also found the ROO aproach a little inmature for my purposes. There are a couple of things like spring4gwt but they just dont seem to fit. Can you help me here?
Regards

I didn’t integrate Spring and GWT, but I am still able to use both (but not with Roo). It’s quite easy to use just as much Spring as you want, so I use Spring on the server-side stuff. (The one inelegant thing is that for GWT RemoteServiceServlets, I have to grab the beans I need in the init() method rather than just injecting it. You may be able to inject them, but I wasn’t sure how to have the container treat it as both a servlet and a Spring bean, so I just kludged it in.

Sorry, but you’re in the wrong place. I never got GWT and Roo working together. It’s not that I would never be able to do it, but it was supposed to be easier, not harder than other ways. You should try the Roo forum. This does seem to be a destination for people frustrated with Roo, though, so if you get an answer, feel free to post a link to the answer here.

Your question does illustrate one of my objections, though, to auto-generated code. Don’t get me wrong; Auto-generated code can be a great time saver if the code generated is a finished product. For example, Java client classes generated from WSDL saves a lot of hand coding. But then you typically just access those classes as a client. You don’t have to go in and tweak the generated code.

Auto-generated code that you have to maintain, though, has the risk of being accidentally overwritten. But to me, the bigger problem is that computer generated code is typically hard to understand. To maintain the UI layer (and you will) you’ll have to have an advanced understanding of GWT. I haven’t looked in a while, but you should also be able to follow some pretty clever AspectJ stuff.

It’s a great project, your expectations are unreasonable because Spring roo doesn’t have release 2 or 3, but 1 … It’s a quite new project. And you expect it to be something that exist 4+ years and that has been extremely refactored in time…

If anything GWT Roo integration doesn’t seem to be tested. It has schoolboy errors in it. The project doesn’t even build.

The GWT code generated is over engineered. Scalable may be, but it certainly is a deal breaker for people wanting to get initial codebase based on ROO and go on their own after the initial setup.

Re Multi project builds, there is an easy fix for it. It is not out of the box but recently i built a core project and built 10 different modules with dependencies on main module. I had to create one extra project to do assembly and sync up application properties and application security xml. It definitely was not a show stopper.

Spring ROO on its own rocks. GWT integration is getting worse by the release. 😦

I believe one major weakness of the tool is that the majority of developers are finding hard to customized the UI. As you can see in my showcases I been able to customize and extend Roo based applications relatively easy.

In addition, I implemented typical enterprise requirements/features like master-detail, charts, column sort just to mention a few and extend Roo in the mobile arena.

Based on the experience with Roo, I can tell you that is great!. The problem -I believe- is in the business side aka management side: Roo is successful for CRUD scope projects but is struggling for making it on the real world Java web development. In particular due the “ROO UI customization issue”.

I believe that Roo management has not realized how critical is to provide paths to connect Roo with real world Java web development. Useful paths that show how Roo can solve typical requirements as be mentioned above.

B. Roogards
jD

Note please remove same reply posted on follow up blog. I believe I should had post my reply here instead there. Thx.

I admit I was excited about Roo when I first read the documentation. The excitement rapidly bled away as I tried time and again to get a useful project constructed. I like Java (being doing it since Java 1.0) and I like Spring… but I don’t belieev Roo is ready for prime time.. .I’d never depend on it in aproject where I had a hard delivery date….

@Cody,
I have to agreed with you in your point “Roo is NOT ready for prime time”…
The technology is fantastic. I implemented a bunch of applications with Spring Roo, so I know what I am saying. Visit my blog in case you an example of full potential of Spring Roo unfolded at http://pragmatikroo.blogspot.com; but what is missing then? Books, tutorials, live-demos, show cases on how-to applied it on real world web apps. The few books available are valuable to certain degree but basically recreate the reference manual over-and-over.
Without a minimum of documentation foundation -knowledge base- it almost impossible that the community embraces any technology.

It sad to say, but I see lesser and lesser interest in Spring Roo everyday, fewer and fewer questions in the forum and fewer tweets as well.

Wow. I wish I had read this article before. that would have saved me lot of troubles. I faced exact same troubles in my last job. tried spring roo with GWT. tried to set up multi-module maven project but didn’t work. so i had to put everything in same module/project. things started working fine until I added a field with one to many relationship among 2 entities. It seems GWT request factory has some troubles with one to many and many to many relationships. Finally we had to drop idea of GWT after 3 weeks of wasting time. This was the only problem I had with Spring Roo so far.

You are so interesting! I don’t believe I have read anything like that before. So wonderful to discover someone with some unique thoughts on this topic. Really.. many thanks for starting this up. This website is something that is required on the internet, someone with some originality!

[…] a little more attention so there’s something for people to read besides that I thought that Spring Roo Sucks (which is too harsh). Therefore, my goal is to have a new post on this blog at least once per week […]