My (first) experience with Spring Roo on a commercial project

My latest development project, a Spring Roo based web application for a local government organisation, is going live within the next few days. This was my first experience of working with Spring Roo (and Spring MVC actually) and I thought it might be interesting to the Spring Roo community to document my experience.
In way of a summary before I go into detail about my experience I thought I would answer myself some of the common Spring Roo questions that get raised by people interested in the technology.


• Is Spring Roo hard to get started with?

Yes and no (not a great answer!). If you are familiar with Spring MVC then I think Spring Roo is a great tool. I came to Spring Roo with a very strong back ground in JEE web application and MVC development but did take time to see how the generated Spring Roo scaffolds could be tailored and modified efficiently.

Without some form of background in JEE MVC frameworks Spring Roo could seem quite daunting. But on the other hand at least you get to work with a well organised code base, something that is quite valuable.

The Dojo JavaScript library was also a source of ‘issues’ when picking up Spring Roo. If you don’t have experience of Dojo and need to customise your Spring Roo forms heavily then maybe Spring Roo isn’t for you at present. I got around my inexperience with Dojo by creating a jQuery only template where I could use my existing experience with that framework. Eventually I got up to speed with Dojo and found it very good – I can see why dropping Dojo for jQuery would be a knee jerk reaction by the team. jQuery as an alternative please…?

• Would you use Spring Roo on a commercial web application project?

My experience of using Spring Roo was on a single developer project where the time lines were not particularly aggressive. This helped and allowed me to get up to speed with Spring Roo and Spring MVC. So for a high profile or tight deadline I would only use Spring Roo if you are familiar with the tool or are experienced with Spring MVC.

I also think Spring Roo is currently better suited to ‘Intranet’ applications rather than an application that requires a top quality user-interface. Not that I am building crappy applications but the user interface polish acceptable in say an internal project is often lower than that needed on a public facing site. Spring Roo produces a quite acceptable interface for this type of application and so I feel currently gives the most benefit in this area.

Looking forward I think using Spring Roo to produce a rock solid (and organised) RESTful back end and then creating a JavaScript client may be the way to go for public facing applications.

• Having used Spring Roo for a project would you use it again?

Absolutely!

I use Spring Roo often to prototype applications, particularly to build quick back-ends for various mobile proposals that I am working on.

I would use Spring Roo on any web application that does not require a highly customised and ‘beautiful’ web interface – for me this means any project with a limited internal audience within an organisation.

I would hesitate before using Spring Roo within a large project team.

So in short I would recommend investigating Spring Roo and, even if it does not suit your current project, checking in again at regular intervals. I started using version 1.1.2 and found by 1.1.5 things had improved markedly. Having looked at 1.2.0 things seem better again and I certainly feel Spring Roo has a future.

I will also highlight my NUMBER ONE TOP TIP here too – use a great Distributed Revision Control System (DVCS) such as Mercurial (or Git) with Spring Roo from the very beginning. And commit all the time, especially before executing a number of Spring Roo commands. If like me you aren’t completely sure what Spring Roo will do (we are all learning this new technology) then having a back stop like Mercurial is essential for your sanity.

If you wish to read some more about my experience with Spring Roo check out the TXT attachement (sorry, size limit on PDFs so had to make it plain text).

And finally thanks to the Spring Roo team and community that have helped me get this project finished successfully.

Chris

Very interesting!

I'm in the same situation as you, and I'd like to make a POST like this, but I'd rather comment yours instead:

- Spring Roo is easy to get started with. The less you know, the more you trust in the way that Roo generates the code.

However, if you want to customize, or to follow the code or to change something, then there is no other option: you need to master Spring framework and know a lot about Spring Roo.

But I don't think it's Roo's blame, but Java's: when the problems come, you need to know JPA, MVN, MVC, AspectJ, Log4J and countless of technologies that a Java EE project involves.

- My project is commercial. And I'd like to use Roo again, but for the time being, the modification of the User Interface is a big burden in Spring Roo ("Dojo, JSTL, pease JQuery" must be the most repeated words in the forum)

My team wasn't large, but using your tip: GIT, GIT, GIT (or Mercurial). will solve the issues. Unfortunately, we have to use Subversion :(

- I had a similar problem with MAVEN. Well, nobody asked me for ANT instead of MAVEN [...], but the Production Application Server is WAS 6.1, and we had to customize a lot the build of the EAR (yepes, an EAR, with the static content in a separate web server, so it can't be included in the WAR)

By the way, what is your final production environment? It seems Oracle DB, what is the application server (if you can tell us)?

My TIP was to use the same database that we will find in Production (DB2), because you have to make a lot of changes in all the entities in order to make the application works (I tried at home with PostgreSQL and MySQL and I found the same problem, specially due to "column definitions". NOTE, I use Hibernate)

My development environment is STS, Roo in a external command shell (in that way is easier to kill Roo if there is a problem), and TC Server (The tomcat version of VMWare) for testing.

Finally: I love Ken Rimple's Spring in action and I recommend it to everybody.

To answer the question in the previous post...

I developed the application running on Windows 7 against Tomcat 6.0.32 and Tomcat 7.0.16 with JDK 1.6. I used Tomcat 7 as it often performed a little better and could reload classes dynamically which meant I could develop a little quicker in some cases.

My client ran Tomcat 6 on Ubuntu Linux 10.04.2 running against OpenJDK 1.6.0_20 (64bit).

Initially I simply used the Hypersonic setup that is initially configured by Spring Roo. Once I was well into the beta phase I introduced an Oracle 11g database. Like I said this was a bit of a pain but really just come down to naming convention issues - but would probably be more annoying on a larger database. I chose to handle the two naming conventions myself in order to be able to still use Hypersonic for my local development and testing which helped keep development reasonably quick.

Great to hear other people working successfully with Spring Roo - I feel it is certainly no worse than other J2EE approaches. And personally I am very hopeful that my next project will really benefit from this experience - less time doing crappy Java dev tasks!

And jQuery or at the very least a non-Dojo template would be very useful. I am pretty happy haven't learnt enough Dojo to get by (it seems neat and consistent compared to jQuery in some ways) but it really will be holding back Spring Roo uptake I would think.

Chris Mein