Effective Grails plugin development with in-place plugins

Plugins are a great way to modularize your applications and reuse common functionalities. The first time I tried to write a plugin my development process was annoying and time-consuming, because I didn't know about in-place plugins.

My workflow consisted of the following steps, which have to be repeated every time:

1. change some plugin code
2. grails package-plugin
3. grails install-plugin
4. grails run-app
5. check plugin changes in main app

So I didn't use plugins for structuring the code for a while, until I found out about in-place plugins, where you can skip a lot of the unnecessary work.

Configure main application for your in-place plugin

You need a plugin under development and a main application where you would like to use it. There you just add the following to your BuildConfig.groovy:
grails-app/conf/BuildConfig.groovy

grails.plugin.location."${pluginName}" = "${pathToYourPlugin}"

Replace the plugin name placeholder with your plugin name and the path to the root directory of your plugin. Check "Specifiying Plugin Locations" in the grails docs Creating and Installing Plugins for further information.

Example for my AdminPanelPlugin used by the AdminTest application:

grails-app/conf/BuildConfig.groovy

grails.plugin.location."AdminPanelPlugin" = "/Users/surelyplus/Documents/workspace/AdminPanelPlugin"

Even IntelliJ has great support for this, so you can see the plugin next to your main app in the Grails View.

Hope this helps you writing more plugins with more fun ( -> like me)!

Easy way to show your application startup time

In this post you will learn a quick & easy way to access the start up time of your Grails application and display the information on a gsp page.

What we have to do is:

1. Access the startup date of your applications context
2. Make the date accessible in a convenient way
3. Format and display the data in your gsp

Accessing the startup date 

First of all we need the time when the context of our application was started. This can be easily accessed via the GrailsApplication instance that can be injected in your Grails Services, Controllers, etc.
This example shows the BootStrap.groovy as starting point, but for production code a real service would be a better choice. So here we go...inject grailsApplication to into our class and get the startup date in milliseconds from the main context.

grails-app/conf/BootStrap.groovy

class BootStrap {

    def grailsApplication

    def init = { servletContext ->
        Long startupDateInMillis = grailsApplication.mainContext.getStartupDate()
    }
}

Make the date accessible in a convenient way

Now you know the startup date, but if you want to display it in a gsp for example you need an easy way to access it. A practical and logical way is to store this meta information in the Grails Metadata along with other informations about your app (such as app version).
Complement the previous code to look like this:

grails-app/conf/BootStrap.groovy

Long startupDateInMillis = grailsApplication.mainContext.getStartupDate()
Date startupDate = new Date(startupDateInMillis)
grailsApplication.metadata.put('app.startupDate', startupDate)

The milliseconds are converted into a real date object and stored under the key app.startupDate (your choice).

Format and display the data

To access the data in a gsp you now have the <g:meta name="app.startupDate"> tag. This can be easily combined with the formatDate to display it the way you like. For the meta tag the gsp function syntax is used to prevent syntax problems while embedding it into the formatDate tag.

grails-app/views/index.gsp

 <g:formatDate date="${g.meta(name:'app.startupDate')}" />

The meta data is also accessible in your controllers or taglibs with the g.meta method, just the way you need it.

That's it!

Breakpoints in trouble - Starring Grails 2.3 and IntelliJ

The new Grails 2.3.0 GA was released lately. Since I am working on a REST API at the moment, I was curious about the REST features introduced in Grails 2.3.0. Soon after I started a little toy project, I wanted to check some controller code, but my IDE ignored all breakpoints! D'oh!

The reason seems to be another new forked execution feature shipping with the Grails 2.3.0 Version.  The gentle reader might get some background information what it's all about from this blog post by Graeme Rocher.

So if you are encountering the same problem, here is a quick fix in your BuildConfig.groovy settings to disable the forked execution and make your breakpoints work again. I got this working solution by this discussion.
The grails.project.fork config parameter to the rescue. Just set the values for test and run to false to disable forked execution like this and do a restart.

grails-app/conf/BuildConfig.groovy

grails.project.fork = [
    test: false,
    run: false
]

Other tips like appending --debug-fork to the run-app command had no effect on my project. Would be nice if you drop me a message which solution worked for you.

Don't panic and happy debugging!