#grails plugins

I've written a number of Grails plugins and the fact is that some of them are effectively unsupported. I've only got so much time & I'm juggling work, family, conference speaking, my own projects and open source. Any plugin development I do is going to be driven by the requirements of work or other projects, so even those plugins I still consider as supported might not get updated as often as some people would like. I'm no longer supporting… * [The Selenium RC plugin][5]. It's based on Selenium 1 which is discontinuted. I contributed to [Geb][11] which is based on Selenium 2 and is actively supported by [Luke Daley][6] & [Marcin Erdmann][7]. You should consider using that. * [The Springcache plugin][2]. It's effectively superseded by the new [Cache plugin][10] which is supported by SpringSource. * [The Spring Events plugin][3]. It does what I need it to do and there are more full-blown solutions such as Rabbit MQ or the platform core events plugin if you need something more. I'm hoping to continue with… * [The Fields plugin][1]. It seems popular & certainly caters to a pain point. That said I'm not using it directly on anything else I'm working on so it's not a huge priority for me. * [The Joda Time plugin][4]. I think it's important and deserves to have first-class support in Grails. The `java.util.Date` and `java.util.Calendar` classes are, to put it mildly, problematic for a whole host of reasons. I'm currently experiencing some frustration trying to integrate the plugin with the unit testing framework in Grails 2+ but I would like to get a new version of the plugin out at some point. * [Angular scaffolding][8]. This is as-yet unreleased but I'd like to work some more on it. * [Betamax][9]. I've done a bunch of work on the next version but have got sidetracked with other things recently. I hope to pick this up again soon. If anyone wants to take over my abandoned projects, please get in touch. I'll be happy to hand you the keys to the GitHub repos. [1]:http://freeside.co/grails-fields/ [2]:http://gpc.github.com/grails-springcache/docs/guide/index.html [3]:http://grails.org/plugin/spring-events [4]:http://gpc.github.com/grails-joda-time/ [5]:http://freeside.co/grails-selenium-rc/docs/manual/index.html [6]:http://ldaley.com/ [7]:http://blog.proxerd.pl/ [8]:http://git.io/grails-ng [9]:http://freeside.co/betamax [10]:http://grails-plugins.github.com/grails-cache/docs/manual/ [11]:http://gebish.org/

Thanks to the [documentation][1] provided on [Adam Goucher's blog][2] I've created a simple Firefox plugin that extends the [Selenium IDE][3] and adds formatters that allow you to export a script as a [Grails Selenium RC][4] test case. You have the option of JUnit 3 (extends _GroovyTestCase_, uses _assertEquals_) or JUnit 4 (doesn't extend anything, uses annotations and _assertThat_) formats. I think everything is working. There are some things I'd still like to do: * Custom commands are currently exported as commented out which they don't need to be given Grails Selenium RC test cases can call Javascript extension functions directly. * I haven't yet figured out how to output a command such as selenium.waitForAlertPresent() rather than selenium.waitFor { selenium.isAlertPresent() } The Firefox plugin is available from [Selenium HQ][5]. You will need to have Selenium IDE installed for it to work, obviously. Once installed you should find options * _Export Test Case As -> Grails Selenium RC (JUnit 3)_ * _Export Test Case As -> Grails Selenium RC (JUnit 4)_ have been added to Selenium IDE's _File_ menu. Whilst I would certainly not leave the exported test case as is it's a quick way to get started. From the exported script you can easily refactor out some page objects or helper methods. [1]: http://adam.goucher.ca/?p=1352 [2]: http://adam.goucher.ca/ [3]: http://seleniumhq.org/projects/ide/ [4]: http://robfletcher.github.com/grails-selenium-rc/docs/manual/index.html [5]: http://bit.ly/daOJpD

Following on from [my previous post][1] I've developed a Grails plugin that packages the asynchronous events behaviour up and adds some extra useful functionality. In addition to the asynchronous event processing the plugin gives you: * A _publishEvent_ method attached to all domain classes, controllers and services. * A Hibernate session bound to the listener thread for the duration of the notification so that listeners can access lazy-loaded properties, etc. * The ability to have a "retry policy" for certain types of failed notifications on individual listeners. This is particularly useful for listeners that do things like invoking external web-services that may be periodically unavailable. To install the plugin just use: grails install-plugin spring-events The code and some more detailed documentation is on [GitHub][2]. I'll be migrating the docs to the plugin's page on grails.org soon. [1]: http://blog.freeside.co/post/42902948889/asynchronous-application-events-in-grails [2]: http://github.com/robfletcher/grails-spring-events

The Selenium RC plugin for Grails has hit version 1.0 with: * Firefox 3.6 support * grabbing of screenshots on test failures * the ability to call JavaScript user extensions on the _selenium_ object as though they were regular Groovy methods among other features. Check out the documentation at [http://robfletcher.github.com/grails-selenium-rc][1] and install with `grails install-plugin selenium-rc`. [1]: http://robfletcher.github.com/grails-selenium-rc

## Isolating each build One thing I found is that it's probably a good idea to specify separate working directory for each build. I found that simultaneous builds would stomp over each other's compiled classes otherwise. This is particularly an issue for me where I have a build for the _Selenium RC_ plugin whilst one of the test apps for the _Springcache_ plugin uses the latest _Selenium RC_ release to run tests. Hudson provides various [environment variables][8] so I just set _grails.work.dir_ to `/tmp/.grails/${JOB_NAME}` in every case. The other consideration is the port that Grails applications will use. If you are running any kind of functional tests the Grails application will start and it each Hudson job needs to use a separate server port or simultaneous jobs will experience port contention. The server port is also configured in the Grails build step. I've just assigned a different one to each job but I couldn't think of a particularly clever way to automate the port assignment. ## Test reports Under _Post-build Actions_ I ticked _Publish JUnit test result report_ then entered a comma-separated set of paths to the XML reports generated by each build step. For example, the _Springcache_ plugin has the following reports configured: target/test-reports/*.xml,test/projects/springcache-test/target/test-reports/*.xml,test/projects/content-caching/target/test-reports/*.xml That's picking up the root plugin's unit test reports and the reports generated by the _springcache-test_ and _content-caching_ test applications. Hudson does a good job of merging these together into a unified test report. ## Running tests that need a browser Some of my tests use _Selenium RC_ which drives a real browser. Given that Hudson is running on a headless box I had to get the display exported to a box with an X Windows environment. ## Still to do Right now all the plugins are building against Grails 1.2.1 only so the next task is to set up parallel builds using Grails 1.3-RC1. Ideally I would like to use Hudson's multi-configuration project capability to do that but I haven't had a chance to look into it yet. I'd also like to use Gradle to build the various project with one build step but I'd lose the convenience in switching Grails versions that the Hudson Grails plugin gives me. [1]: http://4.bp.blogspot.com/_fh9xwLFYBUw/S5ks3ENs8yI/AAAAAAAACbU/vHE684-UsTI/s400/hudson.png [2]: http://hudson-ci.org/ [3]: https://twitter.com/wangjammer5/statuses/10269319705 [4]: http://wiki.hudson-ci.org/display/HUDSON/Grails+Plugin [5]: http://wiki.hudson-ci.org/display/HUDSON/Git+Plugin [6]: http://wiki.hudson-ci.org/display/HUDSON/Github+Plugin [7]: http://wiki.hudson-ci.org/display/HUDSON/ChuckNorris+Plugin [8]: http://wiki.hudson-ci.org/display/HUDSON/Building+a+software+project#Buildingasoftwareproject-HudsonSetEnvironmentVariables

Yesterday I released the new version of the Springcache plugin for Grails. The new feature this brings to the table is page fragment caching driven by annotations on controller actions. The feature is based on [EhCache Web][1] and is even simpler and more powerful than the full page caching [I blogged about recently][2]. With the page fragment caching feature you can: * Define `@Cacheable` and `@CacheFlush` annotations on controller actions. * Have SiteMesh decorate cached and uncached output alike. * Use SiteMesh to mix dynamic page sections with cached sections. * Use SiteMesh and `` to have multiple areas of the page that are cached and flushed independently of one another. * Cache the output of controller actions that use content negotiation separately according to the requested format. There are some examples in the [plugin documentation][3] and the [plugin source code][4] has [a test project][5] with a variety of page fragment caching mechanisms used and tested. [1]: http://ehcache.org/documentation/web_caching.html [2]: http://blog.freeside.co/post/42902815893/full-page-caching-in-grails-with-ehcache-web [3]: http://grails.org/plugin/springcache [4]: http://github.com/robfletcher/grails-springcache [5]: http://github.com/robfletcher/grails-springcache/tree/master/test/projects/content-caching/

There's a fairly popular technique in Grails plugin development where the plugin has 'test apps' stored in `test/projects/*`, each of which references the plugin by including `grails.plugin.location."my-plugin" = "../../.."` in its _BuildConfig.groovy_. Doing this allows you as a plugin developer to: * Automate tests for sample projects using the plugin with significantly different configurations. * Test using domain classes, controllers, etc. that shouldn't be packaged with the plugin. * Test drive, changing code in both the test app and the plugin without the need to use `grails package-plugin` or `grails install-plugin` to pick up changes. The downside is that to run all the plugin project's tests it's necessary to run the plugin's own tests, then change directory into each of the test apps and run their tests. Continuous integration config is also fiddlier for the same reason. I wanted to find a way to automate this so I could run all my plugins' tests with a single command. I could write a _bash_ script or an _Ant_ build I guess, or even use _maven <shudder>_. However keeping things in Groovy-land I decided to try using _[Gradle][1]_ which I've been meaning to look into for a while now. I saw [Hans Dockter's presentation][2] on _Gradle_ at the [London Groovy & Grails Exchange][3] back in December and was impressed with how terse and expressive the syntax is, especially compared to XML based formats. Unfortunately one thing _Gradle_ doesn't grok yet is Grails. The solution I've come up with is based on [a post by Helmut Denk][4] on the _gradle-user_ list. Gradle just uses [Ant's exec task][5] to shell out and execute the appropriate Grails command. Combining this with Gradle's multi-project build support I now have plugin builds that can be run with `gradle test` that will automatically descend into the test apps under _test/projects/*_. The _build.gradle_ file at the root of the project defines _clean_ and _test_ tasks: The _test_ task will run the plugin's unit tests. The _clean_ task is defined just once for all projects as there's no difference in how it is done - a nice examply of Gradle's [DRY][6]-ness. Then in _settings.gradle_ I tell Gradle where to find the various sub-projects: Finally each test app has it's own _build.gradle_ that defines its _test_ task: This is only necessary if the test apps run tests differently to the plugin - here my app is running integration rather than unit tests - otherwise I could have defined _test_ in the same DRY manner as _clean_. The process is not as fast as it could be if Grails were wired in to Gradle properly. `gradle clean test` for the Springcache plugin and its two test apps takes just over 2 minutes on my MBP. Also, my Gradle-fu leaves a lot to be desired right now so I'm sure there are improvements that could be made with the way I'm handling the sub-projects. But, for the purposes of a pre-commit test run or Hudson build this works pretty well. [1]: http://www.gradle.org/ [2]: http://skillsmatter.com/podcast/java-jee/gradle-deep-dive [3]: http://skillsmatter.com/event/java-jee/groovy-grails-exchange-2009/wd-184 [4]: http://www.mail-archive.com/[email protected]/msg01871.html [5]: http://ant.apache.org/manual/CoreTasks/exec.html [6]: http://en.wikipedia.org/wiki/Don't_repeat_yourself

I [posted recently][1] about the new remote mode feature of the [Selenium RC plugin][2]. One thing I forgot to mention is that this feature can also be used to run your Selenium tests interactively against a running app instance. You can start your app as normal using `grails run-app` then either open a second terminal or background the process (_Ctrl-Z_ in a _bash_ shell) then use `grails -Dselenium.remote=true test-app other:selenium __` to run individual tests without stopping or re-starting the app. With the app running _development_ mode you can effectively test-drive using Selenium tests and Grails' artefact reloading capabilities. One thing I should clarify is that direct domain class access will _not_ work in remote mode. I'm thinking about ways to add [fixtures][3] support to the Selenium RC plugin so there's a good alternative approach that will work in remote mode. [1]: http://blog.freeside.co/post/42902733548/selenium-rc-tests-with-a-remote-app [2]: http://grails.org/plugin/selenium-rc [3]: http://grails.org/plugin/fixtures