brew install gradle

It’s very easy to use with a little experience, but I find having a good starting place to base your work from can help.

Here’s a quick function that I’ve got in my .zshrc to bootstrap a new groovy gradle project in the current directory (it should also work in in a .profile/.bash_profile/.bashrc).

function newgradle() {
    echo "Creating files for new gradle project"
 
    cat <<EOF>.gitignore
*.un~
*.iml
*.ipr
*.iws
build
.gradle
EOF
 
    cat <<EOF>build.gradle
apply plugin: 'groovy'
apply plugin: 'idea'
 
repositories {
    mavenCentral()
}
 
dependencies {
    groovy 'org.codehaus.groovy:groovy-all:1.8.6'
    groovy 'org.apache.ivy:ivy:2.2.0'
    testCompile 'junit:junit:4.10'
}
 
task createSourceDirs(description : 'Create empty source directories for all defined sourceSets') << {
    sourceSets*.allSource.srcDirs.flatten().each { File sourceDirectory ->
        if (!sourceDirectory.exists()) {
            println "Making \$sourceDirectory"
            sourceDirectory.mkdirs()
        }
    }
}
 
idea {
    project {
        jdkName = '1.6'
    }
}
EOF
 
    gradle createSourceDirs
 
    git init
    ls -a1 && find src    # list all created assets
}

It creates a build.gradle file ready to work with java and groovy projects, including IDEA integration (just execute gradle idea).

This gives you all of the tasks necessary to compile, jar, test, and distribute your code. For more information, check out the gradle docs on the java, groovy, and idea tasks.

It also creates all the necessary source directories for you and initializes a new git repository (with starting .gitignore file) for you to save your work.

You can easily tweak the build.gradle or .gitignore files to fit your needs. If you don’t use git, you can either delete those lines, or subsitute the equivalent lines for the source control tool you use. These are just a good starting place for me.

Here’s the sample output from the script above:

% mkdir testapp
% cd testapp
% newgradle                                                                   
Creating files for new gradle project
:createSourceDirs
Making /Users/tnaleid/Documents/workspace/testapp/src/main/resources
Making /Users/tnaleid/Documents/workspace/testapp/src/main/java
Making /Users/tnaleid/Documents/workspace/testapp/src/main/groovy
Making /Users/tnaleid/Documents/workspace/testapp/src/test/resources
Making /Users/tnaleid/Documents/workspace/testapp/src/test/java
Making /Users/tnaleid/Documents/workspace/testapp/src/test/groovy
 
BUILD SUCCESSFUL
 
Total time: 2.344 secs
Initialized empty Git repository in /Users/tnaleid/Documents/workspace/testapp/.git/
.
..
.git
.gitignore
.gradle
build.gradle
src
src
src/main
src/main/groovy
src/main/java
src/main/resources
src/test
src/test/groovy
src/test/java
src/test/resources

Then you’ve got all this gradle functionality ready to use:

% gradle tasks                                                           
:tasks
 
------------------------------------------------------------
All tasks runnable from root project
------------------------------------------------------------
 
Build tasks
-----------
assemble - Assembles all Jar, War, Zip, and Tar archives.
build - Assembles and tests this project.
buildDependents - Assembles and tests this project and all projects that depend on it.
buildNeeded - Assembles and tests this project and all projects it depends on.
classes - Assembles the main classes.
clean - Deletes the build directory.
jar - Assembles a jar archive containing the main classes.
testClasses - Assembles the test classes.
 
Documentation tasks
-------------------
groovydoc - Generates Groovydoc API documentation for the main source code.
javadoc - Generates Javadoc API documentation for the main source code.
 
Help tasks
----------
dependencies - Displays the dependencies of root project 'test'.
help - Displays a help message
projects - Displays the sub-projects of root project 'test'.
properties - Displays the properties of root project 'test'.
tasks - Displays the tasks runnable from root project 'test' (some of the displayed tasks may belong to subprojects).
 
IDE tasks
---------
cleanIdea - Cleans IDEA project files (IML, IPR)
idea - Generates IDEA project files (IML, IPR, IWS)
 
Verification tasks
------------------
check - Runs all checks.
test - Runs the unit tests.
 
Other tasks
-----------
cleanIdeaWorkspace
createSourceDirs - Create empty source directories for all defined sourceSets
 
Rules
-----
Pattern: build<ConfigurationName>: Assembles the artifacts of a configuration.
Pattern: upload<ConfigurationName>: Assembles and uploads the artifacts belonging to a configuration.
Pattern: clean<TaskName>: Cleans the output files of a task.
 
To see all tasks and more detail, run with --all.
 
BUILD SUCCESSFUL
 
Total time: 4.871 secs

We decided to leverage git’s history rewriting capabilities to make a much smaller repository (and kept our previous repo as a backup just in case).

Here are a few questions/answers that I figured out how to answer with git and some shell commands:

What object SHA is associated with each file in the Repo?

Git has a unique SHA that it associates with each object (such as files which it calls blobs) throughout it’s history.

This helps us find that object and decide whether it’s worth deleting later on:

git rev-list --objects --all | sort -k 2 > allfileshas.txt

Take a look at the resulting allfileshas.txt file for the full list.

What Unique Files Exist Throughout The History of My Git Repo?

If you want to see the unique files throughout the history of your git repo (such as to grep for .jar files that you might have committed a while ago):

    git rev-list --objects --all | sort -k 2 | cut -f 2 -d\  | uniq

How Big Are The Files In My Repo?

We can find the big files in our repo by doing a git gc which makes git compact the archive and stores an index file that we can analyse.

Get the last object SHA for all committed files and sort them in biggest to smallest order:

git gc && git verify-pack -v .git/objects/pack/pack-*.idx | egrep "^\w+ blob\W+[0-9]+ [0-9]+ [0-9]+$" | sort -k 3 -n -r > bigobjects.txt

Take that result and iterate through each line of it to find the SHA, file size in bytes, and real file name (you also need the allfileshas.txt output file from above):

for SHA in `cut -f 1 -d\  < bigobjects.txt`; do
echo $(grep $SHA bigobjects.txt) $(grep $SHA allfileshas.txt) | awk '{print $1,$3,$7}' >> bigtosmall.txt
done;

(there’s probably a more efficient way to do this, but this was fast enough for my purposes with ~50k files in our repo)

Then, just take a look at the bigtosmall.txt file to see your biggest file culprits.

Purging a file or directory from history

Use filter-branch to remove the file/directory (replace MY-BIG-DIRECTORY-OR-FILE with the path that you’d like to delete relative to the root of the git repo:

git filter-branch --prune-empty --index-filter 'git rm -rf --cached --ignore-unmatch MY-BIG-DIRECTORY-OR-FILE' --tag-name-filter cat -- --all

Then clone the repo and make sure to not leave any hard links with:

git clone --no-hardlinks file:///Users/yourUser/your/full/repo/path repo-clone-name

You can use this command from the parent directory that contains your git repository and it’s clone to see how much space each of them take, and how much you’ve shrunk the repo in size:

du -s *(/)     # add the -h flag to see the output in human readable size formats, just like ls -lah vs ls -la

With these commands, I was able to reduce the file size of our repo with a few thousand commits down below the size of the checked out repository (more than an order of magnitude smaller). I only removed old binary files, we still have full history for all code files.

There are no good-looking, “mac-like” merge tools, but if you swallow your pride there are a few different options for 3-way merges, including Araxis Merge ($$$!), DiffMerge, DeltaWalker, and FileMerge which comes free with XCode.

I’ve tried them all, and find them all confusing. They all tend use a 3-pane display to do the merging with your file in the left pane, the file you’re merging in the right pane, and the messy half-merged file in the middle.

That’s not enough information.

A 3-way merge actually has four important sources of information:

• LOCAL – your file with the changes you’ve made to it
• REMOTE – the file you’re merging in, possibly authored by someone else
• BASE – the common ancestor file that LOCAL and REMOTE came from
• MERGE_RESULT – the file resulting from the merge where you resolve conflicts

You often need to see all four of these pieces of information to make intelligent choices. Where you came from (LOCAL), where the other person’s changes came from (REMOTE), where you both started (BASE) and where you are now (MERGE_RESULT).

Most other 3-way merge tools either conflate or omit the BASE and that can make it harder to see what the right thing to do is.

Kdiff3 is my merge tool of choice. It’s not pretty; it’s cross-platform Qt based so it has a very old-school linux GUI feel to it. But like linux, it’s functional and can help you quickly be productive once you get over the learning curve.

If you’ve got 2 heads that you need to merge in your current repository:

We made this modification to file.txt:

diff --git a/file.txt b/file.txt
--- a/file.txt
+++ b/file.txt
@@ -1,1 +1,1 @@
-BASE: common_ancestor
+LOCAL: file in current working branch

and they made this change to the same file and line:

diff --git a/file.txt b/file.txt
--- a/file.txt
+++ b/file.txt
@@ -1,1 +1,1 @@
-BASE: common_ancestor
+REMOTE: other branch we're merging in

If you run your SCM’s merge command (here, in mercurial: hg merge -r 2), and have kdiff3 configured as your merge tool, you’ll get a pop-up window like this:

As you can see, it shows you all 4 pieces of information, BASE, LOCAL, and REMOTE on top, and the MERGE_RESULT file on the bottom. It currently has a Merge Conflict that you need to fix.

You can move from one unresolved conflict to the next using the triple up and triple-down colored arrows in the middle of the tool bar. When a conflict is highlighted, you can press any combination of the A, B, and C buttons in the toolbar. Pressing one of those buttons will resolve the conflict with the code from pane A, B, or C on top. So if the LOCAL file (your file) had the right changes in it, you’d press B.

It’s possible to press more than one button if code from multiple panes is valid. You can also directly edit the file in the MERGE_RESULT pane to make manual changes if the correct merge is not the exact text in A/B/C.

Another option, if you want to take all of the changes from one file and discard any changes from the others, is to go to the “Merge” menu and pick one of “Choose A Everywhere”, “Choose B Everywhere”, or “Choose C Everywhere”.

Once you’ve resolved your file, simply save it (cmd-S) and quit out of kdiff3. Your SCM should see the MERGE_RESULT no longer has any merge conflicts and will mark it as resolved, ready for you to commit it. If there are other files with merge conflicts, you can repeat the process with those files.

Installing kdiff3

Installing kdiff3 is as easy as downloading the latest version from sourceforge and copying it to your /Applications directory.

The app is a simple wrapper around a Qt-based application. It can be run from the command line at /Applications/kdiff3.app/Contents/MacOS/kdiff3. You can make a symlink of that into your path, but I assume in the instructions below only that you’ve got kdiff3 in your /Applications folder.

Mercurial Integration

Mercurial command line integration is pretty easy. Just open up your ~/.hgrc file (or create one if you don’t have it already), and add this to it:

[extdiff]
cmd.kdiff3 = /Applications/kdiff3.app/Contents/MacOS/kdiff3
 
[merge-tools]
kdiff3.args = $base $local $other -o $output

That configures kdiff3 as your merge tool of choice, so it should pop up automatically when you hit a merge conflict. You can also use it as a diff tool:

hg kdiff3 -r revision_to_compare_to

Git Command-Line Integration

To configure the git command line to use kdiff3 as a diff and merge tool, add this to your ~/.gitconfig:

[difftool "kdiff3"]
    path = /Applications/kdiff3.app/Contents/MacOS/kdiff3
    trustExitCode = false
[difftool]
    prompt = false
[diff]
    tool = kdiff3
[mergetool "kdiff3"]
    path = /Applications/kdiff3.app/Contents/MacOS/kdiff3
    trustExitCode = false
[mergetool]
    keepBackup = false
[merge]
    tool = kdiff3

Now you can use the external tool commands to look at diffs:

git difftool [revision_sha]

and fix unresolved merge conflicts:

git mergetool

Git Tower Integration

I’m normally a pretty hard-core command line user, but I still sometimes find the places I get myself in git confusing enough that I’m willing to use a GUI to get myself out. I think that git-tower is the best git GUI available right now.

It can show you diff files and lets you browse through history in it’s UI. It also lets you do a number of basic and mid-level commands (adding, committing, rebasing, squashing commits, cherry-picking, etc), but it doesn’t have a built-in diff or merge tool.

It does come with the ability to integrate with a few different merge tools out of the box, but not kdiff3.

After a little digging around, I found a generic post showing how configure Tower with a plist file and a shim shell script, but nothing specific to kdiff3.

I figured out how to get Tower and kdiff3 to play nice with each other, and have the instructions and files in a GitHub repository. To get it working, just clone the repository to a temporary directory, and run the install.sh script:

cd /tmp
git clone git@github.com:tednaleid/git-tower-kdiff3-shim.git 
cd git-tower-kdiff3-shim
./install.sh

It simply copies the plist file and the shim script into the appropriate directories (and Tower is very picky about those locations).

Then you need to go into Tower’s Preferences->Git Config control panel, and choose kdiff3 as the diff and merge tool:

For a quick rundown of how Tower works with kdiff3 as a merge tool, here’s an example where we’ve got one commit where we made changes to locally:

And another commit on origin/master where someone else made changes to the same piece of code:

We’ve pulled it down and now have 2 heads within our repository. To fix this, we need to merge and resolve the conflicts, hit the merge button and we’ll get an error message because there are conflicts that git can’t resolve automatically:

If you highlight a file with merge conflicts, and then hit the “Merge Tool” button, it will bring up kdiff3 and let us use it to resolve the issue:

Fix the merge conflicts in kdiff3 (ex: press “C” to change it to “Goodbye Cruel World”), save it, and quit out of kdiff3. Tower should see that the file has had it’s conflicts resolved and lets you commit the merge and carry on.

You can also use Kdiff3 as a regular diff tool if you don’t like looking at diff files. Just choose a file that you’ve modified to diff:

Press the “Diff Tool” button, and it’ll pop up in kdiff3:

Kdiff3 might be homely, but it’s easy to use once you understand how it works.

Install Leiningen

Leiningen isn’t required, but it makes managing the classpath for your REPL quite a bit easier and automates the inclusion of the files in your project so that they can be used in the REPL.

If you’ve already got clojure installed and are managing your classpath some other way, you’ll want to modify the nailgun server script below to remove the call to lein and ensure you’re getting clojure and other classes in the ng-server’s classpath.

Install Leiningen if you don’t have it already.

Download the lein script.

Put it somewhere on your PATH (such as /usr/local/bin or ~/bin).

Set it to be executable:

chmod +x lein

Then, tell it to self-install with this command:

lein self-install

Now you should have a working lein installation:

lein help

And you can create a new clojure project skeleton, with clojure 1.3.0 all ready to go with:

lein new myproj

It creates a skeleton project rectory and a project.clj file that you can use to hold lib dependencies.

Go into that project and you can use lein to go into a repl, get the project’s classpath, run tests, etc. Use lein help to see the full list of commands.

Install VimClojure in Vim

Install the VimClojure plugin in vim.

Hopefully, you’re already using Tim Pope’s vim script management script Pathogen.

If so, you should be able to just clone VimClojure into your bundle ectory:

cd .vim/bundle
git clone git://github.com/vim-scripts/VimClojure.git

If you’re not using Pathogen, install the plugin with your normal process.

Edit your .vimrc, make sure you have these settings if they’re not already there (they need to be after the method that calls pathogen to install bundles):

filetype off
call pathogen#runtime_append_all_bundles()
...
filetype plugin indent on
syntax on

and add these items to your .vimrc

let g:vimclojure#HighlightBuiltins = 1
let g:vimclojure#ParenRainbow = 1

To test that VimClojure is installed OK, edit a clojure file (like this sample one modified from (source +)):

(defn myplus
  ([] 0)
  ([x] (cast Number x))
  ([x y] (. clojure.lang.Numbers (add x y)))
  ([x y & more]
     (reduce myplus (myplus x y) more)))

If the parenthesis are differently colored in matched pairs, that means that “rainbow” parenthesis are enabled and the plugin is working. It should look something like this:

You’ll also want to update the helptags documentation for VimClojure:

:helptags ~/.vim/bundle/VimClojure/doc/

Now you can lookup help for VimClojure:

:help VimClojure

You’ve now got a functioning VimClojure installation that can already be pretty helpful. If you want to get an integrated REPL installed, there’s a bit more to do.

Setting up Nailgun to work with VimClojure

This part is the trickiest part (in the github docs, they say “Here be Dragons”). I think the biggest difficulty is that they don’t show you how to configure/launch the nailgun server, we’ll go through those steps.

Nailgun is a server that runs an instance of the JVM. On startup, you tell it what classpath this JVM should run with. Then, with a nailgun client, you can send it additional classes to execute within that JVM and it can show you the output.

It makes things much faster as the Nailgun server is already running hot when you send it things to execute. You don’t pay any JVM startup penalty.

Warning: If you’ve previously tried to install nailgun through homebrew, it will not work with clojure. The server jar that homebrew uses is half the size of the server jar that we’re going to be using for clojure. Uninstall it or put the things below earlier in the classpath.

Compile the VimClojure nailgun client

We need to compile the VimClojure nailgun client. You can either download the sources directly or else clone the bitbucket repo:

hg clone https://bitbucket.org/kotarak/vimclojure

Go into the client directory and make the ng client executable:

cd vimclojure/client  # or cd vimclojure-nailgun-client
make

This will create an executable called ng in the current directory. Copy that somewhere in your path (likely the same place you put lein above).

You should now be able to type ng and have it spit out help text.

% ng
Usage: ng class [--nailgun-options] [args]
          (to execute a class)
   or: ng alias [--nailgun-options] [args]
          (to execute an aliased class)
   or: alias [--nailgun-options] [args]
          (to execute an aliased class, where "alias"
           is both the alias for the class and a symbolic
           link to the ng client)
 
where options include:
   --nailgun-D<name>=<value>   set/override a client environment variable
   --nailgun-version           print product version and exit
   --nailgun-showversion       print product version and continue
   --nailgun-server            to specify the address of the nailgun server
                               (default is localhost)
   --nailgun-port              to specify the port of the nailgun server
                               (default is 2113)
   --nailgun-help              print this message and exit

Setting up Nailgun Server

Download latest server jar from clojars (currently 2.3.0).

Put that jar somewhere that you won’t delete it, and then add an export for that location in your .bashrc/.vimrc, ex:

export VIMCLOJURE_SERVER_JAR="$HOME/lib/vimclojure/server-2.3.0.jar"

Now save this script as ng-server and put it somewhere in your path and make it executable:

#! /bin/bash
 
if [ -z $VIMCLOJURE_SERVER_JAR ]; then
    echo "Error! Need to define location of VimClojure nailgun server jar with:"
    echo "export VIMCLOJURE_SERVER_JAR=<location>"
    exit 1
fi
 
if [ ! -f $VIMCLOJURE_SERVER_JAR ]; then
    echo "Error! Unable to find VimClojure nailgun server jar at '$VIMCLOJURE_SERVER_JAR'"
    exit 1
fi
 
LEIN_CLASSPATH=$(lein classpath)
 
if [ ! $LEIN_CLASSPATH ]; then
    echo "Warning! Unable to get classpath from lein, just using existing classpath, expecting clojure jars to be available"
fi
 
NG_CLASSPATH="$VIMCLOJURE_SERVER_JAR:$LEIN_CLASSPATH:$CLASSPATH"
echo java -server -cp "$NG_CLASSPATH" vimclojure.nailgun.NGServer
java -server -cp "$NG_CLASSPATH" vimclojure.nailgun.NGServer

Then add this to your .vimrc setup:

" this should only be necessary if you don't have the ng client in your PATH
let vimclojure#NailgunClient = "/path/to/your/ng"
let vimclojure#WantNailgun = 1

Now, from the root of a lein project, make sure you’re dependencies are updated:

lein deps   // puts things defined in project.clj into ./lib by default

Without additional configuration, you’ll likely just have the clojure-1.3.0.jar in there.

The script above leverages lein to create a classpath that the nailgun server can use. If you run lein classpath, you’ll see what it will use:

% lein classpath
/Users/tnaleid/Documents/workspace/clojure-test/myproj/test:/Users/tnaleid/Documents/workspace/clojure-test/myproj/test-resources:/Users/tnaleid/Documents/workspace/clojure-test/myproj/src:/Users/tnaleid/Documents/workspace/clojure-test/myproj/classes:/Users/tnaleid/Documents/workspace/clojure-test/myproj/resources:/Users/tnaleid/Documents/workspace/clojure-test/myproj/lib/clojure-1.3.0.jar

Now, you should be able to start up a nailgun server from the root of a lein project and have it automatically pull in all dependencies, ready to recieve client requests.

Open up the src/leinprojectname/core.clj file in vim. Then press

\sr

to get a REPL window that you can interact with. (if you’ve remapped localleader to something else, replace \ with your custom key)

There are quite a few other things you can do with the REPL, check out :help VimClojure and go down to Keybindings for more details.

Here are some good starter ones:

\el  - eval current line
\eb  - eval current visual block selected
\ef  - eval current file
 
\sr  - start interactive REPL
\sR  - start interactive REPL initialized to have same namespace as current buffer
 
\si  - prompt for input and lookup with (source)
\fd  - prompt for input and lookup with (find-doc)

The Pain is Over, Now Reap the Rewards

Once all this configuration is done, it should be as easy as running the server in a lein project:

ng-server

And then editing your files in vim accessing the embedded REPL whenever you need it.

One of my favorite uses of Dropbox is to sync almost all of the non-machine specific configuration files and directories in my home directory across all my OSX computers (currently my iMac, MacBook Air, and my work laptop).

Doing this lets me make a configuration change to one computer and have it almost instantly available on any other computer without any manual steps.

This is especially important for my zshell and Vim configurations as I’m always tweaking those, but it’s also helpful to have my Documents, Downloads and Pictures shared.

I have a folder in my Dropbox directory called home, I use a script called link.sh to automatically create symlinks in my home directory to the things I’ve got stored in Dropbox.

Dropbox/home currently has these files and directories in it:

.ackrc
.dbvis
.groovy
.gvimrc
.hg
.hgignore_global
.ssh
.subversion
.vim
.viminfo
.vimrc
.zshenv
Desktop-starling.local/   # unique Desktop for my MacBook Air
Desktop-kestrel.local/    # unique Desktop for my iMac
Desktop-thrush.local/     # unique Desktop for my work MacBook Pro
Documents/
Downloads/
Pictures/
bin/

My Dropbox/home directory also has a shell script in it called link.sh:

#! /usr/bin/env bash
cd $(dirname $0)
 
function linkFile() {
    LINK_TO_NAME=$2
    if [ -z $LINK_TO_NAME ]; then
        LINK_TO_NAME=$1
    fi
    if [ -a $HOME/$LINK_TO_NAME ]; then
        echo "**** Found existing $LINK_TO_NAME, skipping..."
    elif [ -h $HOME/$LINK_TO_NAME ]; then
        echo "Already symlinked $LINK_TO_NAME, skipping..."
    else
        echo "Linking $1 to $LINK_TO_NAME"
        ln -s $PWD/$1 $HOME/$LINK_TO_NAME 
    fi
}
 
 
for F in $(ls -a1 | grep -v link.sh | grep -v Desktop | egrep -v "^..?$" | egrep -v "^.*un~$" | grep -v .DS_Store); do
    linkFile $F
done
 
export HOSTNAME=$(hostname)
 
if [ -d "Desktop-$HOSTNAME" ]; then
    linkFile "Desktop-$HOSTNAME" "Desktop"
else 
    echo "Unable to find Desktop-$HOSTNAME to link to Desktop"
fi

What the script does is:

1. cd into the directory that the script is located in (it only symlinks files in the same directory)
2. list out all of the files and directories in the same directory as the script
3. filter out the things we don’t want to link (like ., .., the link.sh script itself, etc)
4. For all of the files/directories that pass the filter, call linkFile to create a symlink in the current user’s home directory as long as there isn’t already a file or a symlink there
5. Then look for a file called Desktop-$HOSTNAME where $HOSTNAME is the name of the current machine and create a ~/Dropbox symlink to it if it’s found.

It should be safe and non-destructive and only create symlinks when there isn’t anything else there with the same name.

I didn’t have my Pictures, Documents, and Downloads in my Dropbox for quite a while and was able to get away with the free 2GB plan. I recently upgraded to a paid Dropbox plan as I wanted those directories shared as well (though I exclude a couple of them from my work MacBook Pro).

For “special” directories like Desktop, Pictures, Documents, and Downloads, I needed to use sudo rm -r [dirname] to remove it before I could create the symlink (BACKUP THE DIRECTORY FIRST).

I’ve been using this for over a year, and haven’t noticed any apps that care that those directories are symlinks.

Also? I have used this shell script many times on my systems, and I think it’s safe, but PLEASE backup before using it, or deleting any directories. An adult crying is not a pretty sight :).

These aliases work for both the grails as well as the grails-debug commands (for attaching a remote debugger).

If there is an application.properties file in the current directory, we can find the current version of grails for the app.

If there isn’t an application.properties file in the current directory, the script just defaults to whatever version of grails you’ve already set up as your default through the standard $GRAILS_HOME environment variable. You can use the grails symlink switching aliases that I created previously to easily move this between versions.

alias grails="execute_grails_version grails"
alias grails-debug="execute_grails_version grails-debug"
 
function execute_grails_version() {
    GRAILS_CMD=$1
    shift
    if [ -f application.properties ]; then
        export GRAILS_VERSION=`grep app.grails.version application.properties | sed -E 's/.*=(.*)/\1/'`
        export GRAILS_HOME="/usr/local/grails-$GRAILS_VERSION"
        echo "application.properties found, using \$GRAILS_HOME of $GRAILS_HOME"
    else 
        echo "application.properties NOT found, leaving \$GRAILS_HOME as $GRAILS_HOME"
    fi
 
    if [ ! -d $GRAILS_HOME ]; then
        echo "ERROR: Unable to find \$GRAILS_HOME directory at $GRAILS_HOME"
        exit 1
    fi
 
    echo $GRAILS_HOME/bin/$GRAILS_CMD $*
    $GRAILS_HOME/bin/$GRAILS_CMD $*
}

UPDATE: There are a few situations where aliases aren’t available (or are a pain to get available) such as when code is being executed as part of another application rather than from the command line. To get around this, these scripts (created by a co-worker of mine, @sjurgemeyer) could be put in your PATH, ahead of your $GRAILS_HOME/bin and used instead of the aliases above:

grails:

grails-version grails $*

grails-debug:

grails-version grails-debug $*

grails-version:

GRAILS_CMD=$1
shift
if [ -f application.properties ]; then
    export GRAILS_VERSION=`grep app.grails.version application.properties | sed -E 's/.*=(.*)/\1/'`
    export GRAILS_HOME="/usr/local/grails-$GRAILS_VERSION"
    echo "application.properties found, using \$GRAILS_HOME of $GRAILS_HOME"
else 
    echo "application.properties NOT found, leaving \$GRAILS_HOME as $GRAILS_HOME"
fi
 
if [ ! -d $GRAILS_HOME ]; then
    echo "ERROR: Unable to find \$GRAILS_HOME directory at $GRAILS_HOME"
    exit 1
fi
 
echo $GRAILS_HOME/bin/$GRAILS_CMD $*
$GRAILS_HOME/bin/$GRAILS_CMD $*

This was right after my talk on using Redis with Groovy and I thought to myself, “this is a perfect example of where a quick redis script could automate this and make it a bit more groovy”. So I threw together this script in about 15 minutes:

The majority of the script is just parsing command line options, the redis portion is very small.

It populates a set of conference attendees from a text file if there isn’t already a set of people there (my sample file just uses conference speakers:

if (!redis.exists("conference-attendees")) {
    new File("./conference-attendees.txt").eachLine { redis.sadd("conference-attendees", it) }
}

Next, it pops a random attendee out of the set of all attendees that haven’t won prizes yet:

def winner = redis.spop("conference-attendees")

It will then add that winner to a hash of prizes mapped to winners.

redis.hset("prize-winners", prize, winner)

The winner is then printed to stdout with println. Pipe the command it through big:

% ./pickLotteryWinner.groovy Groovy in Action 2nd Edition | big

and you’ll get something like this:

If someone isn’t around to claim the prize, just run the script again with that same prize and it’ll replace the last person picked in the hash of prizes to winners.

Forget who won a prize? Just run it with -l to list all prize winners so far:

def printPrizeWinner(prize, winner) { println "$winner wins $prize" }
...
if (options.'list') {
    def prizeWinners = redis.hgetAll("prize-winners")
    println "Prize winners so far:"
    prizeWinners.each { prize, winner -> printPrizeWinner(prize, winner) }
    System.exit(0)
}

Pipe that through big and you’ll get this:

I love how flexible Redis is, and how easy it makes solving problems. If I had been given this problem before redis, I probably would have hacked together something ugly that persisted/read JSON from the file system or maybe a small grails app with Prizes and Winners. With redis, this is a 15 minute problem (and an hour blog post :), instead of a problem that takes an hour or two to solve.

• You can’t attach it to a running grails instance, you need to run grails console from scratch
• You can’t pass it parameters, such as the name of a script you’ve saved
• It’s a swing app, which is always a little wonky in it’s keybindings and it’s behavior
• It’s not <insert your chosen editor>

I got tired of these limitations so I decided to do something about it. I put together a groovy script that uses HTTPBuilder to POST groovy code to a running Grails app that has the grails console plugin installed.

If you’re running this in any non-development environment, you’ll want to ensure that it’s behind some form of authentication. The most popular grails security plugin is Burt Beckwith’s spring security core, so this script comes with built-in support for that.

This script makes it easy to call from any editor that allows you to execute scripts (pretty much every programmer’s editor on the market). At the bottom of the post, I show how to integrate it with Vim (my editor of choice), but it’d be just as easy to script it from TextMate, JEdit, IntelliJ, Eclipse, etc. Any editor that can take the file you’re currently editing and pass it to a shell script.

Here’s my Vim session with a grails script at the bottom and the output from that grails script in another window at the top.

This is the script that makes the magic happen (linked from github so any future tweaks will be reflected below), just grab a copy and save it somewhere in your path.

If you execute the script without any parameters, it’ll show you the usage syntax:

% postCode.groovy 
usage: postCode.groovy [-u username] [-p password] -b baseUrl file
 -b,--baseurl <baseUrl>     The required base url to auth/post to, ex:
                            http://localhost:8080/myapp/
 -p,--password <password>   The password to authenticate with
 -u,--user <user>           The username to authenticate with, null
                            username/password skips authentication

It uses the nifty CliBuilder that’s comes with recent versions of Groovy to parse command line arguments. If your project doesn’t have any authentication, you can simply call it with the -b argument to let it know where your app is running and pass it a script to execute on that running instance:

postCode.groovy -b http://localhost:8080/myapp/ scriptToRun.groovy 
... results of scriptToRun.groovy ...

If your project IS using the spring security plugin for authentication, you can add a username and a password to use for authentication:

postCode.groovy -u admin -p sekrit -b http://localhost:8080/myapp/ scriptToRun.groovy
... results of scriptToRun.groovy ...

The first time that you run it, it might take a little while to run because the Grape Grab annotation is downloading the HTTPBuilder jars and it’s dependencies.

UPDATE: 8/7/2011 The below is no longer necessary with the new @GrabExclude to ignore the groovy dependency.

One sort of screwy thing that I’ve found with the default Grape settings is that it really isn’t that smart about what dependencies it should download again when they’re already satisfied. This can cause a ~30 second pause every time the script is run, which is unacceptable. I posted a message on the Groovy mailing list and the tl;dr fix for it is to increase the ivy.cache.ttl.default timeout in your ~/.groovy/grapeConfig.xml file (use this as a template if you don’t have the file).

<ivysettings> 
  <property name="ivy.cache.ttl.default" value="15m"/> 
...

Example Use with Spring Security Core Plugin

Here’s a quick demo project where the console plugin is protected by the Spring Security Core plugin.

grails create-app demo-post-code
cd demo-post-code
grails install-plugin console

Install the spring-security-core plugin and create the default User and Role domain classes.

grails install-plugin spring-security-core
grails s2-quickstart com.example User Role

Edit grails-app/conf/Config.groovy and add a rule next to the other spring security configuration stating only ROLE_ADMIN users can get to the console plugin:

grails.plugins.springsecurity.controllerAnnotations.staticRules = [
   '/console/**': ['ROLE_ADMIN']
]

Now we’ll need an admin user in grails-app/conf/BootStrap.groovy that has permission to execute code in the console. Edit the bootstrap file to look like this:

import com.example.*
 
class BootStrap {
 
    def springSecurityService
 
    def init = { servletContext ->
        def adminRole = Role.findByAuthority('ROLE_ADMIN') ?: new Role(authority: 'ROLE_ADMIN').save(failOnError: true)
        def adminUser = User.findByUsername('admin') ?: new User(
            username: 'admin', password: springSecurityService.encodePassword('sekrit'), enabled: true
        ).save(failOnError: true)
 
        if (!adminUser.authorities.contains(adminRole)) UserRole.create(adminUser, adminRole)
    }
    def destroy = {
    }
}

As you can see, we’ve created an admin user with the password sekrit.

Now, create a sample script to run in the grails context, something like this:

import com.example.* 
 
println "User count = ${User.count()}"

Now run the app with grails run-app and in another terminal window execute the postCode.groovy script and give it the credentials and the base url to post it to. If you’ve got everything set up, you should see that there’s one User in the database (the admin user that we bootstrapped in :).

% postCode.groovy -u admin -p sekrit -b http://localhost:8080/demo-post-code test.groovy
 
User count = 1

Integrating With Vim

My vimscript skills are pretty much non-existent, and I’m sure there’s a better way to do this, but here’s the code that I’ve got in my .vimrc to bind F7 to executing the current buffer as plain groovy, and binds F8 to executing it as a grails script, with full binding.

Shift-F7/F8 will close the execution window. If you highlight a part of your code in visual mode, it will just post the highlighted code rather than the whole file.

You can also override the default user/password/base url in a grails session by overriding any of these values, either directly in the vimscript or by setting the appropriate environment variable:

let g:grails_user = $DEFAULT_GRAILS_USER
let g:grails_password = $DEFAULT_GRAILS_PASSWORD
let g:grails_base_url = $DEFAULT_GRAILS_BASE_URL

So to test the above script, I’d use this in my .zshrc/.bashrc/.profile:

export DEFAULT_GRAILS_USER='admin'
export DEFAULT_GRAILS_PASSWORD='sekrit'
export DEFAULT_GRAILS_BASE_URL='http://localhost:8080/demo-post-code'

and this script to temporarily change the values using the current directory for the BASE_URL and optionally passing in a user and password

# example usage from root of grails directory: grailsBaseUrlReset myUsername myOtherPassword
function grailsBaseUrlReset() {
    export DEFAULT_GRAILS_BASE_URL="http://localhost:8080/${PWD##*/}"
    echo "DEFAULT_GRAILS_BASE_URL set to $DEFAULT_GRAILS_BASE_URL"
    export DEFAULT_GRAILS_USER=$1
    echo "DEFAULT_GRAILS_USER set to $DEFAULT_GRAILS_USER"
    export DEFAULT_GRAILS_PASSWORD=$2
    echo "DEFAULT_GRAILS_PASSWORD set to $DEFAULT_GRAILS_PASSWORD"
}

You can change them temporarily in vim by changing a value for your current grails session, just hit colon and change the value:

:let g:grails_password = "reallyReallySekrit"

(or you could add them to a different file that you source independently)

Here’s the full script, just add it to your ~/.vimrc and make sure the postCode.groovy script is in your path and you should be set to go:

function! s:copy_groovy_buffer_to_temp(first, last)
  " groovy/java scripts can't start with a # and tempname's normally do
  let src = substitute(tempname(), "[^\/]*$", "vim_&.groovy", "") 
 
  " put current buffer's content in a temp file
  silent exe ": " . a:first . "," . a:last . "w " . src
 
  return src
endfunction
 
function! s:select_new_temp_buffer()
  let temp_file = tempname()
 
  " open the preview window to the temp file
  silent exe ":pedit! " . temp_file
 
  " select the temp buffer as active 
  wincmd P
 
  " set options for temp buffer
  setlocal buftype=nofile
  setlocal noswapfile
  setlocal syntax=none
  setlocal bufhidden=delete
 
  return temp_file
endfunction
 
function! Groovy_eval_vsplit() range
  let temp_source = s:copy_groovy_buffer_to_temp(a:firstline, a:lastline)
  let temp_file = s:select_new_temp_buffer()
 
  " replace current buffer with groovy's output
  silent execute ":%! groovy " . temp_source . " 2>&1 "
 
  wincmd p " change back to the source buffer
endfunction
 
au BufNewFile,BufRead *.groovy vmap <silent> <F7> :call Groovy_eval_vsplit()<CR>
au BufNewFile,BufRead *.groovy nmap <silent> <F7> mzggVG<F7>`z
au BufNewFile,BufRead *.groovy imap <silent> <F7> <Esc><F7>a
au BufNewFile,BufRead *.groovy map <silent> <S-F7> :wincmd P<CR>:q<CR>
au BufNewFile,BufRead *.groovy imap <silent> <S-F7> <Esc><S-F7>a
 
 
" set these up as environment variables on your system, or override
" per session by using ':let g:grails_user = foo'
let g:grails_user = $DEFAULT_GRAILS_USER
let g:grails_password = $DEFAULT_GRAILS_PASSWORD
let g:grails_base_url = $DEFAULT_GRAILS_BASE_URL
 
function! Grails_eval_vsplit() range
  let temp_source = s:copy_groovy_buffer_to_temp(a:firstline, a:lastline)
  let temp_file = s:select_new_temp_buffer()
 
  if strlen(g:grails_user) > 0
      " replace current buffer with grails' output
      silent execute ":%! postCode.groovy -u " . g:grails_user . " -p " . g:grails_password . " -b " . g:grails_base_url . " " . temp_source . " 2>&1 "
  else 
      silent execute ":%! postCode.groovy -b " . g:grails_base_url . " " . temp_source . " 2>&1 "
  endif
 
  wincmd p " change back to the source buffer
endfunction
 
au BufNewFile,BufRead *.groovy vmap <silent> <F8> :call Grails_eval_vsplit()<CR>
au BufNewFile,BufRead *.groovy nmap <silent> <F8> mzggVG<F8>`z
au BufNewFile,BufRead *.groovy imap <silent> <F8> <Esc><F8>a
au BufNewFile,BufRead *.groovy map <silent> <S-F8> :wincmd P<CR>:q<CR>
au BufNewFile,BufRead *.groovy imap <silent> <S-F8> <Esc><S-F8>a

If you’re not a Vim user, it should be easy to integrate with any other editor that allows you to pass the current file to a shell command and display the results. I went a little extra with the vimscript to allow it to post the current buffer (or selected lines within that buffer) without having to save to disk first.

From the command line, create a plist file as root in the /Library/LaunchDaemons directory with your favorite text editor:

sudo vim /Library/LaunchDaemons/io.redis.redis-server.plist

Paste in the following contents and modify it to point it to wherever you’ve got redis-server installed and optionally pass the location of a config file to it (delete the redis.conf line if you’re not using one):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Label</key>
	<string>io.redis.redis-server</string>
	<key>ProgramArguments</key>
	<array>
		<string>/usr/local/bin/redis-server</string>
		<string>/optional/path/to/redis.conf</string>
	</array>
	<key>RunAtLoad</key>
	<true/>
</dict>
</plist>

You’ll then need to load the file (one time) into launchd with launchctl:

sudo launchctl load /Library/LaunchDaemons/io.redis.redis-server.plist

Redis will now automatically be started after every boot. You can manually start it without rebooting with:

sudo launchctl start io.redis.redis-server

You can also shut down the server with

sudo launchctl stop io.redis.redis-server

Or you could add these aliases to your bash/zsh rc file:

alias redisstart='sudo launchctl start io.redis.redis-server'
alias redisstop='sudo launchctl stop io.redis.redis-server'

If you’re having some sort of error (or just want to watch the logs), you can just fire up Console.app to watch the redis logs to see what’s going on.

A while ago, I created a grails script that allowed the execution of a groovy script within the grails context. Using this gant script gives you access to all of the grails domain objects, hibernate session, and other plugins that you have installed into the app, all from the command line.

It had rotted a bit in the grails 1.3 days (I’d last updated it for grails 1.2), but finally got around to updating it to work with the latest version of grails (currently 1.3.5).

I’ve created a mercurial repository to hold a test project for the script so that it’s easy for me to verify that it works with the latest version of grails.

If you don’t have mercurial installed, you can just get the raw version of the file and save it in the “scripts” directory of your grails application.

Then you can create a groovy script that you’d like to execute (often to bootstrap data, or run some periodic process) and execute it with:

grails run-script path-to-script/scriptName.groovy

I often create my groovy scripts within a “grails console” and get them to work there, then save them for later execution by “run-script”.

You can see it in action by cloning the sample project out on bitbucket and executing the sample script I have in it:

hg clone ssh://hg@bitbucket.org/tednaleid/grails-run-script
cd grails-run-script
grails run-script userScripts/createBook.groovy

Which shows:

Welcome to Grails 1.3.5 - http://grails.org/
Licensed under Apache Standard License 2.0
....<more grails output>...
Running script userScripts/createBook.groovy ... ...
it worked!
Script userScripts/createBook.groovy complete! ...
Application context shutting down...
Application context shutdown.