Posts Tagged ‘Grails’

Maven vs Grails

Monday, May 31st, 2010

We have a Grails 1.1 which uses ant + Ivy as its build mechanism. The Ivy configuration has always been wonky, I wasn’t the person who set it up so I’m not exactly sure why it is that way. You would have to run this special ant target, “copy-jars”, which movies the libraries downloaded with Ivy around because some grails command would delete them.  When it came time to upgrade to the latest version, Grails 1.2.2, we wanted to address this problem. One of the new features touted for this release is its maven integration and since we use Maven for several of our other projects we figured this would be a good choice.

Our experiment upgrading to Grails 1.2.2 with Maven integration took a few days to work our way through the errors and gotchas.  In the end we were able to “successfully” upgrade our project – it compiled and passed all the tests. However it didn’t work that well. I’ve included my notes from the upgrade at the end of the post for anyone else who’s trying to do something similar. However in the end Grails + Maven integration sucked for a few reasons.

  • Tests will fail if you do not run a mvn clean in-between. So you can’t run mvn test, fix something then, re-run mvn test again and expect it to work.
  • Running the mvn package command required a larger amount of memory. I had to increase memory available via JAVA_TOOL_OPTIONS=-Xmx512m. This wasn’t required for our old Ivy-based build system nor is it required when using a pure grails build.
  • The build is fragile, minor changes would break in unexpected ways. But the worst part is any errors encountered were always hidden behind java invocation errors masking the real error. This makes debugging the build much harder.
  • In general the integration is very immature, maybe in the future this will improve. But at this state if I can’t recommend this to anyone.

In the end we decided that Maven integration just wasn’t worth it, and we needed something better. The next option we looked at was a pure grails-based build system. This option worked well, there we’re no errors or gotchas like the previous experiment. The best part is that it is able to pull dependencies from Maven without dealing with maven! It’s pretty simple, as described in the manual, just set your dependencies into grails-app/conf/BuildConfig.groovy. That’s it, you’re done. Run “grails compile” and you’re dependencies will be downloaded and the application compiled. This just took a an hour to figure it all out and show it working compared to the days it took getting the Maven integration barely working. In the end I highly recommend using a pure-grails based build, it is a 1000 times better than the traditional Maven integration.
(more…)

Grails HTTP-based test plugins

Wednesday, November 18th, 2009

grails-logoThere are two leading frameworks for doing http-based integration tests within the Grails framework: functional-test and webtest. Both are packaged as grails plugins and accomplish the same task in a similar manner. The main library behind the scene is HtmlUnit. This is a well thought out library for abstracting web conversations, i.e get this url, check that it has a form, click the submit button. It’s basically a headless browser which even supports Javascript. HtmlUnit appears to have taken the mantle from HttpUnit as the premeir library in this small arena. There has only been one release since 2006 for HttpUnit while HtmlUnit has been very active with 11 releases in the same period.

Webtest is the more established project with its first release in 2007. Webtest is provided by Canoo as a free open source plugin to Grails. The tests are run via an Ant script that packages together the test cases and runs through each one.

Functional-test is a relatively new project with its first release in early 2009. Functional test is basically the same as webtests however instead of using the Ant-based scripts everything is based on Junit and implemented in plain old java or groovy.

We’ve chosen to proceed with using the Junit-based plugin for our HTTP integration tests. Our primary reason in deciding to use Junit is that it integrates well with our other unit-based tests which also use Junit instead of using disparate frameworks for the various types of tests. While this plugin may be newer it’s traffic on the mailing lists is growing and substantial.