January 27, 2010 – 5:24 pm
It’s incredibly easy to set up a Hudson project to build a Grails application with the available Grails plugin for Hudson. Every once in a while, however, there’s a little problem that’s been nagging me – merge conflicts within that pesky little application.properties file.
There are several things that cause application.properties to get re-written by Grails, the most common of which for me is installing / uninstalling plugins. Since this is a properties file, the order of the lines is unimportant (they’re just key value pairs, after all), until your build machine does an ’svn up’ and encounters all sorts of conflicts that can’t be resolved automagically.
There are two (well, OK, three) ways to workaround this:
- Tell hudson do to a clean checkout with each build. To do this just make sure the “Use update” box is NOT checked under the subversion modules section of your build configuration. This works well if your project is relatively small and you have a fast connection to your source code repository.
- Revert the application.properties file before the build happens.
- Stop using SVN. Well, I don’t actually know if other SCMs handle this better, but it wouldn’t surprise me. I certainly know of a few that handle it worse!
For the most part I’ve been using option #1 – until I recently added a very large project to the Hudson build… The build time more than doubled – and that’s just unacceptable.
Enter Option #2. In your build configuration, add an “Execute Shell” Build Step that happens BEFORE your Grails build that reverts the file so that the workspace always has the latest and greatest – without conflicts.

Note that depending on how your checkout works, you may need to add the checkout path in front of application.properties, for example:
svn revert yourGrailsApp/application.properties
If there’s a better way, I’d love to hear it. In the mean time, this extra little build step works great!
Posted in Uncategorized | 1 Comment »