Posts tagged ‘grails’

Spring Roo - first impressions

Ok so another productivity tool hits the market - this time its from the big boys at Spring. Spring Roo is an open source software tool that uses convention-over-configuration principles to provide rapid application development of Java-based enterprise software. The resulting applications use common Java technologies such as Spring Framework, Java Persistence API, Java Server Pages, Apache Maven and AspectJ. Spring Roo is a member of the Spring portfolio of projects.

I was able to install and create an application in under 5 minutes with this thing. Which is great for demo but then I took a look at the generated source code and was not too happy. For a framework that claims to pure java RAD framework there is a bit too much AspectJ in the source folder. In fact its silly the amount of files the generator spits out. The documentation tells you that there is “very little” blackbox and that “you should never be editing” the IDT generated files directly. But for a groovy/java developer who has a lot of web application development experience I am just a little nervous with aspectJ polluting my class files the way i don’t want it too. We use dynamic proxies in more frameworks and places than we can care to think about but there is something about compile time weaving that just makes me a little uncomfortable. Of course this could just be my inexperience with acj and aspectJ talking here.

capture

capture

So for one domain there are a total of 5 source files - 4 of which I should not be touching?

The next thing that was a little bit restrictive was the whole domain modelling - its absoloutely great for simple one-one relationships or many to one relationships but it’s not suitable for slightly more complex types. Also I don’t know how the framework will behave with slightly more advanced but common features of Hibernate (if you are using a Hibernate provider) - like custom hibernate types, hibernate collection of items etc.There is little in the documentation about this - so its hit and try or hit the source code of the project to figure it out.

The scaffold views are not bad but too busy .. from a js/css point - frameworks should ship with minimal style sheets.

I am a little disapointed really I was really excited about this. If I have to choose a RAD framework that will work on a standard JVM I will stick to tomcat + grails.

Here are the advantages of grails as I see it:

1. Cleaner MVC - convention is great /controller/view/id type bindings work great

2. Extremely extensible using plugins, this is a huge advantage and there are some pretty good ones out there from charting to security

3. GORM is great and for the most part works OK

4. Scriptable environment - great little tools like grails console

5. Groovy is great and the framework does not prevent you from using pure java when needed

If you use roo productively - let me know and I will give it a shot again.

Debugging grails in IntelliJ Idea with acegi plugin

module settings for debugging grails applications

module settings for debugging grails applications

I am liking IntelliJ more and more every day. So after weeks of justĀ  using intelliJ for Grails without using the debugger I was finally stuck at a point where I just had to inspect a few varriables to debug a problem. So I fired up the debugger. Getting the debugger started on simple Grails applications works like a charm.

The problem happens when you have a slightly more complex configuration and have a lot of plugins. For example I was using the acegi plugin and the applicaiton failed to pick up the jars in the plugins/acegi-x/lib folder. I had to add them manually to the module libs. The other little nigling thing was that the plugins/xxx/src folders were not included in the src path. You have to add them manually. Not too bad - but clicking on the debug button will still give you build failures.

Inside the src/ folder of the acegi plugin sits a folder called template which is not a src file at all its a gsp styled template. I think the plugin internally uses it to generate the domain classes during plugin installation. This folder has to be mannually excluded from the module src path.

Once you have done this - bingo, the debugger works beautifully.