Building Grails 1.3.X from Source

June 19th, 2010 By admin

I ran into a roadblock with GORM recently and I decided to try my hand at modifying the Grails sources to test out a possible fix. More on that later (if I get it to work.) For now, I figured I’d post a simple recipe the will enable you to (a) quickly build Grails from where it lives on github, and (b) start modifying the sources. This will work for you if you work in a Unixy dev environment. If you’re on Windows you can always download Cygwin.

Background Reading

First, if you’re curious about what lies underneath the Grails hood, you’ll probably want to check out these links before stepping through this tutorial:

http://www.grails.org/Developer+Documentation
http://github.com/dima767/grails-internals-handbook/tree/master/chapters/

The “Pull Code And Build” Script

The page referenced by the first link will point you to a HOW-TO page that seems a little stale (http://www.grails.org/Installation.) In particular, there does not seem to be a grails/grails subdirectory underneath http://github.com/grails/grails-core (git://github.com/grails/grails-core.git.) I’m new to Git, so my lack of success with the stock instructions might be due to my simply being confused. The solution that worked for me is given below in script form. Again if you are on a Unixy system, just run it, and it should work.

git clone git://github.com/grails/grails-core.git  grails-core
cd grails-core

# invoke the build script to create a grails distro in your workspace from the sources in HEAD
gradlew assemble

# set your environment to point to this distro
export GRAILS_HOME=`pwd`
export PATH="$GRAILS_HOME/bin:$PATH"

Verifying It Works

At this point you should be able to run your existing apps using the newly built distro. A caveat: you will likely be prompted to upgrade your app, so you might wish to create a new app, which you can do like this:

grails create-app cars
cd cars

grails create-domain-class com.lackey.Car
grails generate-all com.lackey.Car
grails run-app

Now to prove to ourselves that we really are running the sources we think we are, we’ll deliberately mess them up by introducing an exception into the following file:

./src/java/org/codehaus/groovy/grails/web/servlet/GrailsDispatcherServlet.java

Don’t worry about what this class does for now. Take my word: it does something important and we’re going to break it !

Go to this doDispatch() method, and add the lines shown:

@Override
protected void doDispatch(final HttpServletRequest request,....

request.setAttribute(LOCALE_RESOLVER_ATTRIBUTE, localeResolver);

HttpServletRequest processedRequest = request;
HandlerExecutionChain mappedHandler = null;
int interceptorIndex = -1;

//       ADD THE FOLLOWING 3 LINES TO INTRODUCE GLITCH
if (1>0) {
   throw new RuntimeException("EVIL LURKS");
}

Now, go back to the sample app we created above and re-run it. You should now see the following exception when you try to nativate to the ‘car’ controller at http://localhost:8080/cars/car/index.

Error 500:
Servlet: default
URI: /cars/car/index
Exception Message: EVIL LURKS
Caused by: Request processing failed; nested exception is java.lang.RuntimeException: EVIL LURKS

You now know how to mess up the Grails source base. Adding something useful is left as an exercise for the reader.

How To Change The Grails Source More Than Once

My next post walks you through some of the snags that you might encounter if you make subsequent changes to the source and do builds without clearing out your Ivy cache.

Share: