Simple REST server with Grails

I have recently worked on two small projects that need a simple data store for more intelligent clients. Choosing REST was a no-brainer after some discussion. Grails’ HTML CRUD interface is a great template to start off with, but it lacks dealing with XML/JSON.

Neo4J as a Grails backend

This post is a reply to @EmilEifrem‘s twition.

Neo4J could be a nice extension as a Grails’ persistence backend, similar to a DB, space or LDAP. The problem today is that GORM is tightly coupled to Hibernate. Looks like @GraemeRocher is in the works of extracting Hibernate as a plugin, from which one can use other persitence plugins. Absolutely looking forward to that. (Graeme, please document what defines the folders which contain domain classes, controllers and views, so they can be changed!).

@Nawroth recommended using Neo4J through a JCR layer, though theres no implementation for Grails or Neo4J. The motivation for this is to be able to use the nice features such as MyPersonNode.find(), trinity.save() … Recommend watching this clip 4 intro to Grails.

What can be done today is just using the Neo4J jar in Grails as it is. But the magic of  GORM that makes Grails so different, compared to regular Java won’t exist…

Grails impresses yet again with its plugins – Todays tidbit: SoundManager

Grails and its plugins doesn’t cease to impress me. I tested out the Grails SoundManager plugin today, which is a thin gsp wrapper around a javascript library for playing mp3’s in a webpage. The documentation is short, has all you need to know, and Grails fixes the rest. Just what I need for creating my web-playable music “shop”.

Update – SoundManager will also play videos and streamed content 😀

Grails 1.1 got Maven support – So What?

You know you’ve been wasting too much time blogging in the sphere when, renowned developers start stalking YOU 🙂
Anywho, the comment I recieved informed me that Grails 1.1 Maven support is out, giving Maven developers much needing air-mileage towards a Grails firstclass-citizen-goldcard. Predecessor Octo was, what I reckon, a shell around Ant scripts for doing Grails tasks, distancing Maven from responsibility of doing the nitty-gritty building and wiring.

So why should you care who builds your Grails project?

Because of the nifty reusable plugin functionality you get out of the box from maven. And more importantly with Grails, control of how you wire your app together.

The current state of the new Maven plugin

I can’t see no Ant anywhere. It might be because I’ve been lazy and havent poked around the poms, but until contradicted, I choose to believe that Maven is in charge. One difference is the added folders, src/main/webapp aso. Does it work as it should yet? Of course not, it wouldn’t be bleeding edge if it did, but well enough for me to get a good impression and a list of issues to report back on.

Conclusion

If the Maven plugin picks up speed inside GrailsDev, I’m a happy camper! Good Work!

What I’m into right now

I thought I’d post updates on what I’m interested in, to give a glimpse of what I’m looking into and have moved away from. Perhaps I’ll have enough data to create a graph someday 🙂

Up and coming

• Neo4J – A graph store – no more ORMappings
• Qi4J – A composite development framework, a new way of writing Java applications, a way of life
• Groovy GRAILS – Excellent for prototyping Java stuff
• Mercurial – When thinking different, why not Version Control as well?
• Swing Appframework, Java6u10 – Propably the next big thing in Rich Internet Applications
• Visualization of graphs – Am looking for a nice, easy API for creating several hierarchical trees that I can drag and manipulate
• Amazon EC2 – Java enabled servers on demand!
• Twitter, Blog, IRC -New (and revisited) ways of communicating intra-project/company
• javaBin, JavaZone – Working with the JavaZone conference for a year was damn fun!
  

Reading up on Groovy and Grails

The good thing about Groovy is its likeness to Java, and reading Groovy code should pose no difficulty to a seasoned Java programmer who’s taken a days worth reading. The problem with Groovy is writing good code. Not because you do it wrong, but you can always write it better! As with Ruby, there are alot of nifty features in the language that shortcuts ugly code in Java. But, you have to know that these features exists before you can use them. Grails? It just might become the next dogma in Java application development!

This is the litterature list and resources I’ve used in my pursuit of becoming a Groovier developer:

Dissecting Grails for Maven building

Show me your war, and I will tell you how it does!

Upgrading a Java project from a legacy buildsystem to Maven involves lots of reverse engineering to understand how the application works. Starting to investigate a project by its deliverables is often the most easy, taking a working application and picking away piece by piece, like dissecting a frog, to see if it still works after some abuse and halfchanced guesswork.

I started by grails create-app‘ing a simple book tutorial grails app, and grails war‘ing it. The contents of the war were extracted into src/main/webapp of a maven demo project, supported by groovy-all, GMaven (Groovy Maven plugin) and Maven Jetty plugin.