Ted Naleid

At work, we’re using mercurial for our source control. As we’ve released code to production we’ve needed to branch our repository to support what’s in production as well as ongoing development.

By default, grails uses ~/.grails as the working directory. If you’re doing branchy development, you can run into problems with this if you’ve got plugins installed in one branch that aren’t in the other. Having a unique directory per branch prevents you from having to run grails clean all the time.

Here’s a quick shell script that changes the grails working directory to have the branch name as a suffix if your source is contained in a mercurial repository (ex: the default branch would be ~/.grails_default and the 1.0 branch would be ~/.grails_1.0). If your application is not in a repo, it just uses the regular ~/.grails directory.

#!/bin/sh
HG_BRANCH=`hg branch 2>/dev/null`
GRAILS_SCRIPT=$GRAILS_HOME/bin/grails
 
if [ $HG_BRANCH ]; then
	GRAILS_WORK_DIR=`echo ~`/.grails_$HG_BRANCH
	echo "** grails working directory: $GRAILS_WORK_DIR"
	$GRAILS_SCRIPT -Dgrails.work.dir=$GRAILS_WORK_DIR $@
else
	echo "** default grails working directory"
	$GRAILS_SCRIPT $@
fi

Just save this script as “grails” and put it in your PATH before the $GRAILS_HOME/bin directory (also make sure that you’ve defined $GRAILS_HOME). I have a ~/bin directory that’s the first thing in my PATH.

If you use the grails-debug command, you can repeat these steps for that, just change GRAILS_SCRIPT to $GRAILS_HOME/bin/grails-debug.

This same technique could easily be modified to be used for other source control systems such as git or subversion.

I’ve finally released version 1.0 of the grails build-test-data plugin.

If you’re not familiar with build-test-data, the quick summary is that it puts a build() method on all grails domain objects. Calling that method will automatically construct and save an instance of that domain object that conforms to all of the domain’s constraints. It also allows you to override the values that you want to explicitly set. It makes your tests much cleaner and less fragile as you only need to specify the values that actually matter to a particular test method instead of building a huge graph of objects just to satisfy constraints.

The plugin has been quite stable for the past 6 months or so, and has survived upgrades from grails 1.0.X through grails 1.2.1 with minimal changes. Because of this, I’ve decided to move the version from 0.2.3 to 1.0 to indicate that the plugin is stable and ready to be used. I’ve also added the LICENSE file releasing the plugin under the Apache 2.0 open source license (the same license as grails). It was always open source, but I had neglected to add the official license file in the past.

If you’re not familiar with the build-test-data plugin, the documentation on the wiki is thorough, I’ve also given a presentation on build-test-data that explains why it’s better than other existing data generation technologies.

The biggest changes for this release compared to the last are a number of bugfixes around making sure that both sides of a one-to-many relationship get populated correctly and that there isn’t a need to refresh() from the database.

Previously, if you had an Author that hasMany Books, and each Book belongsTo an Author, you’d need to refresh the Author if you tried to build a new book with an existing author:

Author eap = Author.findByName("Edgar Allan Poe")
Book b = Book.build(author: eap, title: "The Tell-Tale Heart")
 
assertEquals eap.name, b.author.name  // works, linked in OK previously
assertEquals 1, eap.books.size() // FAILED previously WORKS now, previously the book wasn't added properly to the author side of things

The previous workaround was to call eap.refresh() to reload the author from the database, or to have the user manually addToBooks(b). Both solutions were ugly and kludgy and this issue has now been fixed.

Inspired by this question on stackoverflow, I decided to create a utility class that allowed me to determine generically what calls a closure makes (without actually letting it make any calls). This lets me see what it’s trying to do before letting it actually do it.
Read the rest of this article »

A while ago I blogged about my grails testing aliases and how much time they save me.

I’ve made some enhancements to them in the interim that have made them even easier to use.

The most important alias is gtaf, which is short for “grails test-app” for failed tests.

It will search through your test output directory and look for any tests that failed. If it finds any, it will rerun only those tests. Otherwise, it will rerun all tests. That makes it easy to just use gtaf all the time. If any tests fail, it will open them up using Console.app.

If you’re not on OSX, or would like to use something else to view the failed test logs, just modify the testlog alias to do something different.
Read the rest of this article »

I’ve just released a quick plugin that I put together tonight to help render markdown text as HTML within a grails application. It leverages the MarkdownJ library.

I’m a big fan of storing information in markdown format as it is easy to read, easy to write, and easy to transform. A number of big websites like stackoverflow.com support the entry and display of markdown text to help people format their questions and answers without having to remember to properly format HTML.

If you’re unfamiliar with Markdown there are a number of good references on it’s use.

The grails markdown plugin is a very basic plugin. Currently, it just wraps the markdown libarary with a single TagLib that lets you easily render html from a markdown string within your gsp pages.

To install it, just type:

grails install-plugin markdown

To use it in your gsp file:

<markdown:renderHtml>
The *four* cardinal directions are
 
- North
- South
- East
- West
</markdown:renderHtml>

renders the html:

<p>The <em>four</em> cardinal directions are</p>
<ul>
    <li>North</li>
    <li>South</li>
    <li>East</li>
    <li>West</li>
</ul>

Or you can use the “text” attribute of the taglib:

<markdown:renderHtml text="${post.body}"/>

See the Grails Markdown Wiki and source for more details.

I’ve spent some time over the last couple of weeks working on a Grails service that allows us to import new records into our MySQL database.

A number of interesting techniques have popped out of this that I think would be useful for others doing similar types of importing using GORM/Hibernate/MySQL. Read the rest of this article »

I’ve just released the latest version of the grails build-test-data plugin. This version has a couple of bugfixes that were reported by users. Including one with a nice patch including a test from Robert Fletcher (patches with tests are always appreciated).

For those that aren’t familiar with the plugin, it make creating testing data easy.

It automatically adapts to changes in your domain classes and makes your integration tests easier to write and much less fragile.

Resources

• Documentation on BitBucket
• Build-Test-Data Presentation

Overall, the plugin has been very stable for the past few releases and I’m thinking about just bumping the version up to 1.0 fairly soon. The plugin seems pretty feature complete when balanced with it’s ease of use. Most of the other features I’ve thought of would explode the complexity level of the plugin and defeat it’s purpose. Might be best to leave well enough alone for now :).

I had a hell of a time with the current grails release-plugin cycle (6 attempts before it finally went through). The grails release-plugin command uses an old version of svnkit that’s only compatible with svn 1.5. I’ve long since upgraded to 1.6 on my mac, though luckily I did it through macports and still had the old version available to activate (sudo port deactivate subversion && sudo port activate subversion @1.5.6_0).

I did some searching around to find out how to install an old version of subversion, but didn’t come up with anything after a quick google so I might be screwed after my wipe/reinstall for snow leopard next week till Grails patches things with svnkit 1.3.

I did open up a JIRA ticket for grails to upgrade to svnkit 1.3, and I was surprised that there wasn’t already a ticket open on it (and that trunk still had svnkit 1.2 in it).

This is a continuation of a sporadic set of blog posts about some practical uses for groovy metaprogramming.

Groovy Config DSL Overview

In Java, configuration is normally done with properties files. They’re kind of a pain because they’re inflexible, don’t allow executable code, and don’t easily provide a heirarchy.

Groovy greatly improves on Java by building in support for a simple configuration DSL using the ConfigSlurper. Read the rest of this article »

I gave a presentation tonight on the build-test-data grails plugin at the Groovy Users of Minnesota (GUM) meeting that was well received.

Lots of good questions from the people in attendance. Thanks to everyone for showing up.

Here’s a version of it on slideshow: Read the rest of this article »

A recent blog post, Cedric Beust asks about how to cleanly implement “soft asserts”. Soft asserts are test assertions that don’t “fail fast”. Instead, all of the assertion failures in the test method are collected and reported at the end of the test.

So far, the proposals in the comments look fairly clunky to me and include defining whole sets of new methods like “assertEqualsButContinue(“foo”, “foo”)”, chaning assertions together jQuery-style, or using lists to hold all of our assertions.

Wouldn’t it be a lot nicer if we could continue to use the same methods that we’re already using?

In groovy, enabling soft assertions is easy with a little closure magic. Read the rest of this article »