bookorganizer

At my customer, we are using a proxy server, and sometimes it’s handy to have access to GitHub, for example to the Grails repository, or my own Grails Fitnesse repo. I struggled a while to get this to work, but apparently, it couldn’t be easier:


export HTTPS_PROXY='http://10.0.0.1:3128'
git clone https://bodiam@github.com/bodiam/grails-fitnesse.git


Mind the S at the export. Using the https protocol, you can commit your changes over https instead of using the git protocol, and it’s still really fast.

At Tuesday, May the 8th, The NLGUG is organizing a new meetup about Grails in the Cloud.

The meetup will consist of a talk by Maikel Alderhout, who is an expert on the topic, and will be followed up by Pair Deploying, in which pairs will deploy an existing Grails application to a PaaS of their choice, for example CloudBees, CloudFoundry, Heroku, OpenShift or JElastic.

The meetup is free, and will be kindly hosted by Quince, who will also be providing food and drinks! So if you want to join, checkout the meetup page and join us!

When developing plugins, in my case the Grails Fitnesse plugin, it’s sometimes handy to produce output to the user. In my case, I had a use case to give the user some information that Fitnesse had started up succesfully, and wanted to indicate the location Fitnesse was running on.

In previous versions of Grails (1.3.x), you could do ant ant.echo. However, as described in the Grails 2.0 release notes, the ant.echo doesn’t work anymore, and you’ll have to use ‘alternative mechanisms for output’.

Well, Spring Security Core had this already figured out. Just send a StatusUpdate event, which will be printed to the console automatically.

target('default': 'Starts Fitnesse Server') {
    printMessage "hello world!"
}

printMessage = { String message -> event('StatusUpdate', [message]) }
errorMessage = { String message -> event('StatusError', [message]) }

This be handy in the future for other plugin developers.

In Grails 2.0, you need to use mockCommandObject to test command objects. However, what the Grails documentation doesn’t mention is how to use the mockCommandObject method. The mockCommandObject method is located in the ControllerUnitTestMixin. To use the method, you can use the following example:

package nl.jworks.test

import grails.test.mixin.TestMixin
import grails.test.mixin.web.ControllerUnitTestMixin

@TestMixin(ControllerUnitTestMixin)
class CreatePersonCommandTests {

    void testInvalidConstraints() {
        CreatePersonCommand command = mockCommandObject CreatePersonCommand
        command.name = ''

        assert !command.validate()
    }
}

This is a little inconvenient if your class needs a lot of properties. To make things a little easier, you can mock the command object in the setup method (using JUnit’s @Before annotation), and use the default constructor (with Map support), as you would normally:

package nl.jworks.test

import grails.test.mixin.TestMixin
import grails.test.mixin.web.ControllerUnitTestMixin
import org.junit.Before

@TestMixin(ControllerUnitTestMixin)
class CreatePersonCommandTests {

    @Before
    void setup() {
        mockCommandObject CreatePersonCommand
    }

    void testInvalidConstraints() {
        CreatePersonCommand command = new CreatePersonCommand(name:  '')

        assert !command.validate()
    }
}

Another night of coding, another update on the Discobot project! For those unfamiliar with the Discobot project: it’s the project name for running Groovy on Android. We (Marcin Erdmann and Erik Pragt) are working towards an easy to use framework to run the newest version of Groovy on the newest version of Android. Currently, we’re not there yet, but we will demonstrate our progress at the next Groovy and Grails Exchange in London.

A small update though on our current progress, since it has been a while since our last update, and we’ve gotten a few requests to update you all. To start with: the project is still very alive, and we are working hard to create a streamlined environment for developing Groovy Android applications, including Gradle support, with some tasks to easily deploy your Groovy application on the Android emulator.

The last couple of weeks we’ve been struggling to work with the dynamics provided by Groovy. Groovy works a bit different compared to the standard Java runtime in Android. A small example:

class B {
  def pub() {'a'}
} 

def x = [pub: {'b'}] as B

This code dynamically creates a class at runtime. We have to make the Android environment aware of these classes, which is done by the DiscobotClassloader. This is quite tricky to accomplish, but the good news is, that after some days and nights of coding, it works now. Basic Groovy code, like

[1,2,3].each { println it }

was already working for quite some time, but now we support a great deal of the features provided by Groovy already at the moment. Even though we haven’t measured yet how far we are exactly in terms of features, but we’re on the right way.

What we’ll do now though, is to create an Android application which will run all Groovy unit tests. We’ve done it before, and around 30% of the unit tests worked on the Android emulator. Now, with the support for dynamically generating classes, which was one of the biggest problem, we should get far above this 30%. So, please bear with us and we’ll keep update you on the progress we’ll make. In the meantime, you can follow the progress we’re making in our Git repository!

After some hectic times at work caused by very tight deadlines and me getting married in the beginning of September we finally managed with Erik to get back to working on Discobot last week.

Some of you have probably already noticed that we have a talk on Discobot scheduled at Groovy & Grails Exchange 2011 in London which takes place in early December. Although the progress is good there is still quite a lot of work to be done on Discobot and we decided that probably one evening a week will not be enough. On the other hand knowing about the talk gives us an even stronger motivation to succeed!

Last week Erik continued his work on getting all Groovy tests running in the emulator. We found out that ‘on the fly generated’ classes which are created by Groovy when you for example cast a map of closure into a class using ‘as’ keyword cannot be loaded by the classloader. The reason is simple – classloader looks for class files but it should be looking for dex files. This is our main concern at the moment as it causes exceptions all over the place and breaks anything more complex than a ‘hello world’. From the code written by Hjalmar we’ve noticed that he also encountered the problem and we’re trying to apply his solution to see if it will work. So, it looks like there’s a lot of class loading fun ahead of us!

We’ve also got a response from guys behind Gradle plugin for Android about our pull request. They had several small remarks which I managed include in my second pull request. From what they said it looks like they should accept it in the coming days.

I’ve also looked for options regarding a repository in which to put our artefacts (Gradle plugin and the modyfied version of Groovy). I’ve found a nice blog about creating a a github based Maven repository and using it with Gradle. It seems easy and straightforward so probably we will go for this solution for now.

There might be different reasons for setting a browser window size for your Geb tests. For us it was simply the fact that some floating elements where overlapping with other elements rendering them unclickable when the browser window was set to occupy only the half of the screen and that’s the default size of a Firefox window started by Webdriver.

There were two requirements for the solution – it had to work on every machine the tests were run without any configuration (so we had to discard all of the solutions involving changing the Firefox profile) and also the window had to be maximized for each of our tests. Unfortunately WebDriver doesn’t allow to easily control browser window size, at least as long as this issue isn’t solved. Therefore we had to revert to resizing the window via Javascript which we don’t like, but it seems to be the only solution for now. Thanks to putting the code into our GebConfig.groovy we got the window maximized for every test. Following is the driver closure we needed to put in our Geb config:

driver = {
    def driver = new FirefoxDriver()
    driver.executeScript("window.resizeTo(screen.width, screen.height)")
    return driver
}

Note that you can use a similar technique to not only maximize but also set the window to a certain size and to do it on a per test basis if you put the resizing code into your test instead of the GebConfig.groovy.

The Friday Repost series are copies from my earlier writings. Since I don’t want to loose them, and they might prove useful to others, I’m reposting them on this blog

In our development environment, we use the complete Atlassian suite. We (or actually I) choose this environment because the products integrates so well together, but also because it integrates good with other products, like SpringSource Tool Suite, or, in our case, IntelliJ IDEA. And finally, the Atlassian suite has excellent support for building Grails projects, which, at the moment, is all we do. Simply put, we choose Atlassian because it rocks!

To integrate even better with the Atlassian Build Server (Bamboo), I’ve created a small script which will update the version number of the application with the Build Number. This way, we always know which build is running where. To do so, I created the following script.

includeTargets << grailsScript("_GrailsEvents")

target('default': "Sets the current application version") {
    def buildNumberFile = new File('build-number.txt')
    if (buildNumberFile.exists()) {
        def props = new Properties()
        buildNumberFile.withInputStream { stream ->
            props.load(stream)
        }

        def buildNumber = props["build.number"]

        metadata.'app.version' = metadata.'app.version' + ".${buildNumber}"
        metadata.persist()
        event("StatusFinal", ["Application build number updated to ${buildNumber}"])
    }
}

This script will look for a file called ‘build-number.txt’, which is produced by the Build Number Stamper Plugin, and put in the working directory. This file is read by the script, and it updates the version number in application.properties, which will result in a war file produced by the build in the following format ‘-..war’, for example ‘todolist.0.1.34.war’. This way you can easily relate each build which bugs you might find, and avoids confusion, for example between testers and developers.

As an extra, we’ve show the current version of the application in the source of our HTML. We do this by reading the version number from the application.properties with the following tag:

This will display the version number of the application, and will allow you to relate issues to a build number, to avoid miscommunication about the deployed application!

The Friday Repost series are copies from my earlier writings. Since I don’t want to loose them, and they might prove useful to others, I’m reposting them on this blog.

Making Grails work behind an NTLM firewall (or using Grails without Internet)

Currently, I’m in the process of taking over an existing Grails project and migrating it to a different location. This location has been setup by me, so I have full control over it, except for one tiny detail: the Proxy Server.

The application used to work great, and installing plugins was a breeze: just do a good old ‘grails install-plugin fitnesse’, and the plugin would be installed. However, since this Proxy Server is not just any Proxy Server, but a Microsoft NTLM Proxy Server, we tried quite hard to make Java work with it, but at the moment the score is 1-0 for the Proxy Server. This gives us the following problems:

1) Our dependencies cannot be downloaded
2) Our plugins cannot be be downloaded
3) Some plugins cannot be installed anymore

Downloading dependencies
In our BuildConfig.groovy, we specified some dependencies like joda time and xstream. These dependencies are normally downloaded, but due to our Proxy issue, that doesn’t work.

Our solution to this is to use Nexus. Nexus is able to pass the firewall, and can download our dependencies. It serves as a transparent Maven proxy, which can also be used by Ivy, and solves our problem nicely. Besides, it’s a good idea to install a local Maven proxy anyway, mostly because of reliability, but also because of speed and making sure everyone uses the same dependencies.

Downloading plugins
Unfortunately, the Grails plugins are not in a Maven repository. However, a solution to this is to download the plugin zip (eg grails-fitnesse-0.2.zip), rename it (to fitnesse-0.2.zip), put it in the lib directory (even though I’m really not a fan of putting binaries in version control systems), and register it in the application.properties and BuildConfig.groovy.

The BuildConfig.groovy should look like this:

grails.project.dependency.resolution = {
    inherits "global" // inherit Grails' default dependencies
    log "warn" // log level of Ivy resolver, either 'error', 'warn', 'info', 'debug' or 'verbose'
    repositories {
        mavenRepo "http://172.30.60.106:8081/nexus/content/repositories/central" // nexus repo
    }
    dependencies {
        compile ('com.thoughtworks.xstream:xstream:1.3.1') {
            excludes "stax","stax-api"
        }
    }

    plugins {
        runtime ':hibernate:1.3.2'
        runtime ':tomcat:1.3.2'
        runtime ':fitnesse:0.2'
    }

As you can see, everything is configured here: the dependencies are here, the location to nexus is configured, and there’s a plugin closure. This “plugins” closure defines the plugins, and allows you to place them in the ‘lib’ directory. Be sure to rename the plugin zip to remove the ‘grails’ part, else it doesn’t work. Maybe these zips are also available from a Maven repository, which would solve the issue of putting binaries in our source control system, but I haven’t been able to find them yet.

Plugin installation
Some plugins, like the jQuery plugin, but also like my own plugin, the syntax-highlighter, download resources from the Internet when installing them. I haven’t been able to work around that yet, but my current solution is to just not use those plugins. I downloaded the jQuery javascript libraries and attached them to the project myself, and since we only use jQuery which does that, this solution is also an adequate fix.

Conclusion
So, as you can see, with some effort, it’s possible to make Grails work behind a Proxy Server, or without internet at all. This is a good solution for build servers, so you can have reproducible builds without the need for an Internet connection.