A snag in my Grails Script

Yesterday, I blogged about doing a build/deployment from a standalone Groovy script. However, I discovered what I think is a bug in GrailsScriptRunner that prevents System properties from being passed in from external script runners (such as the GrailsTask Ant task or even from Gradle). This kinda sucks, so I'm investigating a couple of possible workarounds, or patching GrailsScriptRunner to fix the problem.

Adventures in GrailsBuilding (and Deployment)

For one of my recent Grails projects, I wanted to do some scripted build and deployment. There seems to be a ton of options available. I've recently been using Capistrano for a *Rails* project, which is pretty much the de facto standard on that side of the world. Capistrano is pretty powerful, but I'd rather not mix apples and oranges, and I much prefer Groovy over Ruby.

In Grails/Groovy land, we have Gant (Groovy wrapper for Ant), which is a Make-like facade around Groovy AntBuilder. We have Gradle, which is what the Grails scripts use.

In the end, I decided to go with simple Groovy + AntBuilder. My initial version of the script just does two things -- it runs the Grails War task, then uses JSch to scp the warfile to a bunch of servers. Even for just these two simple tasks, a bit of fancy footwork was required.

First of all, I wanted to define the deploy configuration in a Groovy Config file read in using ConfigSlurper. This format easily allows switching between different environments in a highly readable format.


def env = args[0]
def config = new ConfigSlurper(env).parse(new File('deployconfig.groovy').toURL())


Next, running the Ant GrailsTask was non-trivial. There are lots of references on the web to people having problems similar to mine -- for whatever reason, GrailsTask is not compatible with Ant 1.8, which is what is included in Groovy 1.7. One interesting thing I figured out was that AntBuilder hard-codes the Ant logging level to INFO. To set it to DEBUG, you can do this:


def ant = new AntBuilder()
ant.project.getBuildListeners().each {
it.setMessageOutputLevel(Project.MSG_DEBUG)
}


IN the end, I ended up having to downgrade to Groovy 1.6. MacPort makes this a pretty simple process (including the ability to easily switch back and forth between versions) that is documented very well here.

Next, I use Grape to download the dependent jars (grails and jsch). I do this within the script to make it as self-contained as possible. Unfortunately, the Grape API changed from Groovy 1.6 to 1.7, so I had to do the following to add the repositories to Grape:


def groovyVersion = org.codehaus.groovy.runtime.InvokerHelper.getVersion()
println "Groovy version $groovyVersion"

if (groovyVersion.startsWith("1.6")) {
Grape.resolve(name:'jsch', root:'http://jsch.sf.net/maven2/')
Grape.resolve(name:'grails', root:'http://repository.codehaus.org/')
} else {
Grape.addResolver(name:'jsch', root:'http://jsch.sf.net/maven2/')
Grape.addResolver(name:'grails', root:'http://repository.codehaus.org/')
}


Finally, to get the GrailsTask to run, I had to set up a classpath for it:


def grailsHome = System.getenv('GRAILS_HOME')
ant.path(id:'grails.classpath') {
fileset(dir:"$grailsHome/dist") {
include(name:"grails-bootstrap-*.jar")
}
fileset(dir:"$grailsHome/lib") {
include(name:"groovy-all*.jar")
include(name:"ivy*.jar")
include(name:"gpars*.jar")
include(name:"gant_groovy*.jar")
}
}
ant.taskdef(name: "grails", classname: "grails.ant.GrailsTask",
classpathref: 'grails.classpath'
)
ant.grails(home:grailsHome, script:'War')


The final step to copy the WAR file is pretty simple:

config.hosts.each { host ->
def commonParams = [
keyfile: config.keyfile,
username: config.username,
passphrase: '',
trust: true
] // these are parameters that are used for any SSH-related tasks
ant.scp(commonParams +
[
file: 'target/app.war',
todir: "${config.username}@$host:/${config.deployDir}"
]
}


Just a random side note... I sure wish the Groovy Object class included each(). It's REALLY convenient to be able to pass objects that may either be individual instances or Collections back and forth. Having to check for a Collection is unnecessary. If this were implemented, my config file could contain either:
hosts: 'hostname'
or
hosts: ['hostname1','hostname2']

instead of the more bulky
hosts: ['hostname']

When I get some more time, I want to look more closely at Gradle. But for now, my standalone Groovy script will suit my needs just fine.

Rebirth

Well, I certainly (as most bloggers do) had grand hopes for providing more content than once every 4 months. I've had a plethora of "a-ha" moments since my last psot, followed by "wow, I've got to blog about that", followed by "wow, am I really gonna blog about that before doing XXX."

Anyways, (as most bloggers are wont to do), I'm going to promise to try to write a bit more often. It'll help if you guys give me an occasional prod. :-)

This last week, I became a proud card-carrying member of the Apple developer community, having purchased a 13" 2.4GHz MacBook Pro so that I could do native development on a couple of projects I'm working on.

My initial thoughts are that I'm very much smitten by the whole Mac ownership experience. It's so....NICE having a computer and OS that doesn't freeze every 10 minutes for some random activity, whose bluetooth works seamlessly, where having a UNIX shell isn't the bastardized hack that Cygwin has become, and I can have the oodles of apps that I like to have open at once with zero impact on performance.

My big growing pain has been adjusting to the differences in keyboard layout and shortcuts. Those of you who know me well know that I live and die by the keyboard, only resorting to mouse/trackpad as a last resort. And while my fingers have almost gotten used to where to go to hit control-A to go to the start of a line, switching back and forth between PC and Mac keyboards is still a problem for me. I'm sure I will adapt, eventually.

As far as development goes, the XCode SDK is still a bit of a mystery to me, but I'm slowly figuring it out. Luckily, I'm not having to learn Objective C yet, although that is certainly around the corner.

I did figure out one really weird problem that was plaguing me, and while I'm usually quite adept at Googling for solutions to problems like this, I couldn't find any references to it. So, here's a quick summary in the hopes that it will help someone out:

I was able to build and run my app with no problems, both in the simulator and on my device. But then I wanted to archive a build to send as an ad hoc distributable, I ran into problems. I selected "Build and Archive", a dialog box popped up that said:

"Unable to create application archive directory. To view or change permissions, select the item in the Finder and choose File > Get Info."

Sounds reasonable. Only, I had no clue where this "archive dirctory" was. Must be in the project settings somewhere, right? Nope. XCode preferences? Uh uh. Probably a trivial task for someone more familiar with this environment to dig into whatever XCode's equivalent to makefiles is to figure this out, but for noob me, I was stumped.

I did find a script that performs the build and archive steps from the commandline. Running this script produced a similar error to the dialog I was getting in XCode - with the additional useful information of the directory name
/Users/xxx/Library/Application Supprt/Developer/Shared/Archived Applications

And sure enough, the directory was owned by Root and permissions were 755, so one quick chown and I was back in business.

I'm not sure how the permissions got screwed up in the first place or whether I did something that caused the permissions to get changed, but hopefully this will help someone who encounters the same problem.

Until next time...