Both. I started working on this little project a couple of months back using Hudson v1.395 and returned to it after the great divide happened. I took it as an opportunity to see whether there would be any significant problems should I choose to move permanently to Jenkins in the future. There were a couple of hiccups- most notably that the new CLI jar didn’t work right out of the box- but overall v1.401 of Jenkins worked as expected after the switch. The good news is the old version of the CLI jar still works, so this example is actually using a mix of code to get things done. Anyway, the software is great and there’s more than enough credit to go around.

The API

Jenkins/Hudson has a handy remote API packed with information about your builds and supports a rich set of functionality to control them, and the server in general, remotely. It is possible to trigger builds, copy jobs, stop the server and even install plugins remotely. You have your choice of XML, JSON or Python when interacting with the APIs of the server. And, as the build in documentation says, you can find the functionality you need on a relative path from the build server url at:

“/…/api/ where ‘…’ portion is the object for which you’d like to access”.

This will show a brief documentation page if you navigate to it in a browser, and will return a result if you add the desired format as the last part of the path. For instance, to load information about the computer running a locally hosted Jenkins server, a get request on this url would return the result in JSON format: http://localhost:8080/computer/api/json.

{
  "busyExecutors": 0,
  "displayName": "nodes",
  "computer": [
    {
      "idle": true,
      "executors": [
        {
        },
        {
        }
      ],
      "actions": [

      ],
      "temporarilyOffline": false,
      "loadStatistics": {
      },
      "displayName": "master",
      "oneOffExecutors": [

      ],
      "manualLaunchAllowed": true,
      "offline": false,
      "launchSupported": true,
      "icon": "computer.png",
      "monitorData": {
        "hudson.node_monitors.ResponseTimeMonitor": {
          "average": 111
        },
        "hudson.node_monitors.ClockMonitor": {
          "diff": 0
        },
        "hudson.node_monitors.TemporarySpaceMonitor": {
          "size": 58392846336
        },
        "hudson.node_monitors.SwapSpaceMonitor": null,
        "hudson.node_monitors.DiskSpaceMonitor": {
          "size": 58392846336
        },
        "hudson.node_monitors.ArchitectureMonitor": "Mac OS X (x86_64)"
      },
      "offlineCause": null,
      "numExecutors": 2,
      "jnlpAgent": false
    }
  ],
  "totalExecutors": 2
}

Here’s the same tree rendered using GraphViz.

This functionality extends out in a tree from the root of the server, and you can gate how much of the tree you load from any particular branch by supplying a ‘depth’ parameter on your urls. Be careful how high you specify this variable. Testing with a load depth of four against a populous, long-running build server (dozens of builds with thousands of job executions) managed to regularly timeout for me. To give you an idea, here’s a very rough visualization of the domain at depth three from the root of the api.

Getting data out of the server is very simple, but the ability to remotely trigger activity on the server is more interesting. In order to trigger a build of a job named ‘test’, a POST on http://localhost:8080/job/test/build does the job. Using the available facilities, it’s pretty easy to do things like:

• load a job’s configuration file, modify it and create a new job by POSTing the new config.xml file
• move a job from one build machine to another
• build up an overview of scheduled builds

The CLI Jar

There’s another way to remotely drive build servers in the CLI jar distributed along with the server. This jar provides simple facilities for executing certain commands remotely on the build server. Of note, this enables installing plugins remotely and executing a remote Groovy shell. I incorporated this functionality with a very thin wrapper around the main class exposed by the CLI jar as shown in the next code sample.

/**
 * Drive the CLI with multiple arguments to execute.
 * Optionally accepts streams for input, output and err, all of which
 * are set by default to System unless otherwise specified.
 * @param rootUrl
 * @param args
 * @param input
 * @param output
 * @param err
 * @return
 */
def runCliCommand(String rootUrl, List<String> args, InputStream input = System.in,
        OutputStream output = System.out, OutputStream err = System.err)
{
    def CLI cli = new CLI(rootUrl.toURI().toURL())
    cli.execute(args, input, output, err)
    cli.close()
}

And here’s a simple test showing how you can execute a Groovy script to load information about jobs, similar to what you can do from the built-in Groovy script console on the server, which can be found for a locally installed deployment at http://localhost:8080/script.

def "should be able to query hudson object through a groovy script"()
{
    final ByteArrayOutputStream output = new ByteArrayOutputStream()
    when:
    api.runCliCommand(rootUrl, ['groovysh', 'for(item in hudson.model.Hudson.instance.items) { println("job $item.name")}'],
            System.in, output, System.err)

    then:
    println output.toString()
    output.toString().split('\n')[0].startsWith('job')
}

Here are some links to articles about the CLI, if you want to learn more :

• Hudson CLI wikidoc
• Jenkins CLI wikidoc
• A template for PHP jobs on Jenkins
• An article from Kohsuke Kawaguchi
• A nice tutorial

HTTPBuilder

HTTPBuilder is my tool of choice when programming against an HTTP API nowadays. The usage is very straightforward and I was able to get away with only two methods to support reaching the entire API: one for GET and one for POST. Here’s the GET method, sufficient for executing the request, parsing the JSON response, and complete with (albeit naive) error handling.

/**
 * Load info from a particular rootUrl+path, optionally specifying a 'depth' query
 * parameter(default depth = 0)
 *
 * @param rootUrl the base url to access
 * @param path  the api path to append to the rootUrl
 * @param depth the depth query parameter to send to the api, defaults to 0
 * @return parsed json(as a map) or xml(as GPathResult)
 */
def get(String rootUrl, String path, int depth = 0)
{
    def status
    HTTPBuilder http = new HTTPBuilder(rootUrl)
    http.handler.failure = { resp ->
        println "Unexpected failure on $rootUrl$path: ${resp.statusLine} ${resp.status}"
        status = resp.status
    }

    def info
    http.get(path: path, query: [depth: depth]) { resp, json ->
        info = json
        status = resp.status
    }
    info ?: status
}

Calling this to fetch data is a one liner, as the only real difference is the ‘path’ variable used when calling the API.

private final GetRequestSupport requestSupport = new GetRequestSupport()
    ...
/**
 * Display the job api for a particular Hudson job.
 * @param rootUrl the url for a particular build
 * @return job info in json format
 */
def inspectJob(String rootUrl, int depth = 0)
{
    requestSupport.get(rootUrl, API_JSON, depth)
}

Technically, there’s nothing here that limits this to JSON only. One of the great things about HTTPBuilder is that it will happily just try to do the right thing with the response. If the data returned is in JSON format, as these examples are, it gets parsed into a JSONObject. If on the other hand, the data is XML, it gets parsed into a Groovy GPathResult. Both of these are very easily navigable, although the syntax for navigating their object graphs is different.

What can you do with it?

My primary motivation for exploring the API of Hudson/Jenkins was to see how I could make managing multiple servers easier. At present I work daily with four build servers and another handful of slave machines, and support a variety of different version branches. This includes a mix of unit and functional test suites, as well as a continuous deployment job that regularly pushes changes to test machines matching our supported platform matrix, so unfortunately things are not quite as simple as copying a single job when branching. Creating the build infrastructure for new feature branches in an automatic, or at least semi-automatic, fashion is attractive indeed, especially since plans are in the works to expand build automation. For a recent 555 day project, I utilized the API layer to build a Grails app functioning as both a cross-server build radiator and a central facility for server management. This proof of concept is capable of connecting to multiple build servers and visualizing job data as well as specific system configuration, triggering builds, and direct linking to each of the connected servers to allow for drilling down further. Here’s a couple of mock-ups that pretty much show the picture.

Just a pretty cool app for installing Jenkins

This is only very indirectly related, but I came across this very nice and simple Griffon app, called the Jenkins-Assembler which simplifies preparing your build server. It presents you with a list of plugins, letting you pick and choose, and then downloads and composes them into a single deployable war.

Enough talking – where’s the code???

Source code related to this article is available on github. The tests are more of an exploration of the live API than an actual test of the code in this project. They run against a local server launched using the Gradle Jetty plugin. Finally, here’s some pretty pictures for you.

[Show as slideshow]

[View with PicLens]

Related posts:

1. A Grails App Demoing the StackExchange API
2. Five Cool Things You Can Do With Groovy Scripts
3. Groovy inspect()/Eval for Externalizing Data

    +----------------------+-------+-------+
    | Name                 | Files |  LOC  |
    +----------------------+-------+-------+
    | Controllers          |     1 |    42 |
    | Groovy Helpers       |     1 |    47 |
    +----------------------+-------+-------+
    | Totals               |     2 |    89 |
    +----------------------+-------+-------+

Please note that this is about as minimal as you could reasonably get away with(and kinda ugly to boot), but nevertheless it does manage to implement a UI and backend for exercising the entire API in a total of 2 gsp files and 1 controller action. What’s noticeably missing are some tailored views for each of the different JSON responses and the implementation of additional query parameters on the calls.

StackExchange API

This is really pretty well documented and “consistent”. Calls in some cases require an {id} in the url and that’s about it. Each of the individual calls has its own help page that describes the options, like the badges page for instance. To make things a little more helpful while exploring the API, each of the implemented endpoints in this app are also hyper-linked to the corresponding manual page on api.stackoverflow.com.

RESTful Access

Couldn’t be a whole lot easier than using HttpBuilder, which provides nice and concise ways to execute the GET request, inspect the response and deal with success/failure of the request. Aside from assigning the root domain and method using variables, this is little different from the canonical example on codehaus.

def http = new HTTPBuilder("http://api.$domain")
http.request(GET, JSON) {
    uri.path = "/${VERSION}$method"
    headers.'User-Agent' = 'Mozilla/5.0 Ubuntu/8.10 Firefox/3.0.4'
     response.success = { resp, json ->
        answer = json
    }
     response.failure = { resp ->
        answer = "Unexpected error: ${resp.statusLine.statusCode} : ${resp.statusLine.reasonPhrase}"
    }
}

The syntax here could probably get even Groovier using the Grails REST client plugin wrappers, and indeed incorporating that plugin is how the HttpBuilder dependency is being provided in this app, but I hit on a working implementation first time out so we’ll leave that for another day, shall we?

What’s it Look Like?

Did I mention it was ugly? Where the API call requires a parameter, you get a text field. Each domain gets its own submit button, officially representing my first attempted usage of g:actionSubmit in Grails. Doesn’t work quite the way I expected, but it does certainly work. Click a button and you’re shown the raw JSON result, along with the call you made. In an ugly fashion, or did I say that already? Still, for a couple of hours of hacking, I’m not unhappy with the result.

StackApps

This is where the apps in the contest get shown off and, in a wonderful display of dogfooding, it’s guess what – another StackOverflow clone! The page for this application can be found here. And the source code is up on github if you’d like to take a look.

Next Steps?

Toying with the idea of porting this to appengine, which would unfortunately mean replacing HttpBuilder and the underlying Apache HttpClient in favor of something that didn’t use a threaded approach, most likely using URL fetch. That and some slightly less ugly tabular and/or tree views of the JSON responses would be kinda nice to have.

Related posts:

1. Hooking into the Jenkins(Hudson) API
2. Grails-UI DataTable using XML for a model
3. Gource Visualizations of the Groovy/Grails/Griffon Projects

Where Hibernate Validator Shines

Annotations on domain classes allow for easily validating object state at the time of persistence. Excellent integration with frameworks like JBoss Seam allow this same ability to be utilized for validating web forms on the client-side with little more than an <s:validateAll/> tag. Seam practically hides the entire interaction with validation components from the developer. Since validation rules are defined directly in the domain class, you can (almost) guarantee that no objects with inconsistent state will ever end up being saved in your database. There are certain validations that aren’t possible to verify without actually looking in the database, unique constraints for example, but generally in my experience hibernate validator is extremely easy to configure and work with. Implementing CRUD functionality is pretty trivial, and UIs can achieve consistency since all validations are applied equally.
Alternatively, if you can’t or don’t want to use annotations for some reason, you can specify your validation rules in an xml file. Usually a singleton validation.xml file is made available on the classpath and picked up automagically when a ValidationFactory is created. A simple xml configuration looks like this:

<constraint-mappings xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemalocation="http://jboss.org/xml/ns/javax/validation/mapping validation-mapping-1.0.xsd" xmlns="http://jboss.org/xml/ns/javax/validation/mapping">
    <default-package>org.kar.test</default-package>
    <bean class="ValidateTestableClass">
        <field name="name">
            <constraint annotation="javax.validation.constraints.NotNull">
        </constraint>
    </field>
</bean>

and is meant to be applied to this simple class:

class ValidateTestableClass
{
    int id
    String name
    String description
    boolean enabled
}

Comparing with Grails Validation

Grails automatically provides validation capabilities for domain classes and command objects, and enables adding the same behavior to any pogo through a combination of the @Validateable annotation and a static constraints closure. Adding validation support to arbitrary classes also requires specifying which packages to scan for the annotation.
Plugin support from projects like bean-fields simplifies the handling of client-side validation and rendering error markers in the UI, an ability which the Grails framework provides natively by adding an ‘errors’ field directly onto the domain or command object class instances bound to a web form.

Dynamic Constraints

Both the hibernate validator and the Grails strategies for applying validation described here have the same limitation: both are universally applied to all instances of a class. There’s no easy apparent way to override those constraints at runtime, although I suspect that some fancy MOP’ing or configuration could probably be used to accomplish overrides at runtime.
Hibernate validator also supports creation of ad hoc validators by seeding with one or more xml documents. Or if you’re like me and hate hand editing xml, you can leverage Groovy to take a bit of the pain away. Here’s the same xml snippet from above in a Groovy Closure, generated simply by turning the DomToGroovy class loose on the raw xml:

looseConstraint = {
        mkp.declareNamespace(xsi: 'http://www.w3.org/2001/XMLSchema-instance')
        'constraint-mappings'(xmlns: 'http://jboss.org/xml/ns/javax/validation/mapping',
                'xsi:schemaLocation': 'http://jboss.org/xml/ns/javax/validation/mapping validation-mapping-1.0.xsd') {
            'default-package'('org.kar.test.objects')
            bean('class': 'ValidateTestableClass') {
                field(name: 'name') {
                    constraint(annotation: 'javax.validation.constraints.NotNull')
                }
            }
        }
    }

Losing all the angle brackets is a good start, but we really haven’t saved a lot of typing. Until you start taking advantage of the ability to define more complicated structures. Note the use of a list structure here to apply NotNull constraints to multiple fields.

strictConstraint = {
        mkp.declareNamespace(xsi: 'http://www.w3.org/2001/XMLSchema-instance')
        'constraint-mappings'(xmlns: 'http://jboss.org/xml/ns/javax/validation/mapping',
                'xsi:schemaLocation': 'http://jboss.org/xml/ns/javax/validation/mapping validation-mapping-1.0.xsd') {
            'default-package'('org.kar.test.objects')
            bean('class': 'ValidateTestableClass') {
                ['name', 'description'].each {
                    field(name: it) {
                        constraint(annotation: 'javax.validation.constraints.NotNull')
                    }
                }
                field(name: 'id') {
                    constraint(annotation: 'javax.validation.constraints.DecimalMin') {
                        element(name: 'value', '2')
                    }
                }
                field(name: 'enabled') {
                    constraint(annotation: 'javax.validation.constraints.AssertTrue')
                }
            }
        }
    }

Applying Dynamic Constraints

Applying constraints is as simple as converting Closures to xml and mapping them to a Configuration object, which then supplies a Validator to use. StreamingMarkupBuilder is utilized to create the xml behind the scenes.

    /**
     * Create a configuration object passing closures as validation mapping documents.
     * @param closures closures to render into validation mapping documents
     * @return config
     */
    public Configuration createConfig(Closure... closures)
    {
        Configuration config = Validation.byDefaultProvider().configure()
        closures.each {
            config.addMapping(new ByteArrayInputStream(GroovyXmlConversionUtil.convertToXml(it).bytes))
        }
        config
    }

I haven’t tested the use of multiple mappings extensively, but minimally each class you’re configuring must be confined to a single mapping – you can’t extend the validations by layering configurations on top of one another. You should however be able to map constraints for different classes in separate Closures.

Crying out for a Builder!

Going from Closures to xml is a quick and dirty way to test out this functionality, but what would really be nice is a Builder that could create an appropriate validation environment more directly. At the least it would allow for removing the namespace declarations and explicit package naming that make up the bulk of the content.

So what do you get?

1. 1. Ability to declare validations against any existing Java or Groovy class without changing the source code
2. 2. Programmatic ability to create the configuration of validations
3. 3. A choice of which validations to apply at runtime
4. 4. Consistency with the behavior of domain class validation

And what’d I get? A fun bit of quick coding on a Saturday afternoon. Nice! Source code is available on git-hub if you want to check it out.

Related posts:

1. Groovy and CSV: How to Get Your Data Out?
2. Jira Grails Plugin
3. Breaking Weak CAPTCHA in… slightly more than 26 Lines of Groovy Code

Gource

Gource is a software version control visualization program with support for Git, Mercurial, and with a tiny bit of extra effort, CVS and Subversion. It’s available as a macport install, as is the ffmpeg program used to stitch together a series of screenshots into the final video.  All of these visualizations were created with Git or Git-svn. When the Gource program is running it brings up an interactive window so you can interact with it to a degree, affecting the camera, zoom, etc.  The default resolution is 1024×768 but I tried to bump it up to 1920×1080. I’m assuming that stretched the limits of the rendering, as there’s quite a bit of pixellation in the final product; either that or the ffmpeg params need to be tweaked. The three visualizations on this page were all created using this one-liner command line invocation (broken down here over several lines for readability).

gource -1920x1080 --highlight-all-users --bloom-intensity .3 -a 1 -s .01
     --hide-dirnames --hide-filenames --stop-at-end --output-ppm-stream -
     | ffmpeg -y -b 3000K -r 60 -f image2pipe -vcodec ppm -i -
     -vcodec libx264 -vpre default  gource.mp4

Groovy

From the initial commit on August 28, 2003, Groovy has come a long way. I tried the Gource provided python script to translate an svn log file into the required format the first time, but cloning the repository with git-svn seemed to produce better results. It’s interesting to see that the overall structure of the Groovy project doesn’t look like is has changed very much over the years. I recognized a lot of the names you see on the screen. Be sure to watch the 1080p version if you’re having trouble reading the text and see if you can’t find some recognizable committers.

Click here to view the embedded video.

Grails

Starting on Sunday March 14, 2004 here’s how it all unfolded, at least from the perspective of the public Git repository. Grails looks like it grew a little more spontaneously than Groovy; there are more frequent restructurings and some transitions that seem to cover a whole lot of ground in very little time. In particular watch out for the burst of activity in the summer of 2009.

Click here to view the embedded video.

Griffon

September 17, 2008 marks the first commit for Griffon and this short but sweet video explodes right from the start. Benefiting greatly from the Grails model this project shows a lot of progress in a very short time indeed. Most, if not all, of the names you see here you probably caught in the previous two videos as well.

Click here to view the embedded video.

What’s the Point?

Watching these gives me (and maybe you) some appreciation for how much effort over time it takes to bring a new language/framework/technology to maturity and all of the individual contributions that go into it. Gource provides a lot more detail into the actual structure if you want to dig in. For purposes of keeping these images fairly uncluttered I removed file and directory names and just focused on the committers and the general structure. I think I gained a git of insight into how a codebase can evolve, and properly appreciate that organizing the increasing complexity of an ever-growing system over time is not a simple job. Plus they look cool. Enjoy!

Related posts:

1. Bamboo, Grails and Git for Continuous Integration
2. A Grails App Demoing the StackExchange API
3. Grails-UI DataTable using XML for a model

This plugin integrates the IDE with one or more components of the Atlassian application suite. Multiple instances of Jira, Fisheye, Bamboo and Crucible can all be configured and used to streamline the development workflow.

Jira

This is perhaps the most essential piece of the puzzle, and inevitably the part a developer is going to interact with the most – the issue tracker. From within the IDE Jira master view you can load filters(basically stored searches for issues), do ad hoc searches and start work on a particular issue. If you drill down to a particular issue you can comment on it, assign it to yourself or another user, log work against it and generally manage it in most of the ways you can from the Jira web interface. Granted it’s not quite as pretty as the web interface, but the essential information and interaction is all there, and if you’re missing something an action is provided to open any issue in a web browser.

What really works for me is how the interaction supports my general workflow so closely:

Granted, I’m not the best at remembering to pause the timer, but being confronted with the time when I commit forces me to honestly evaluate how much time it took to complete the task when it’s clearest in my mind. And incidentally, while we’re here, the option to automatically organize imports in the commit dialog, a built in IDE function, has saved my butt from maven dependency-analyze any number of times.

It’s also convenient that you can see all comments and attachments for issues – viewing a screenshot describing a UI issue is pretty much essential after all, don’t you think?

Bamboo

So once your code is committed, a build is kicked off on Bamboo. Hopefully all goes well, but if any build you’re listening to fails the IDE will give you a message to that effect. You also have access to changes, tests and any associated build logs. And whether or not your build does fail, stacktraces from the log are immediately available and clickable in the IDE. In addition, you can manually trigger builds and label or comment them.

Fisheye

Integration with Fisheye is bi-directional between the IDE and the Fisheye webview. Context menus are available on right clicks in the IDE that open a file in Fisheye. And in the Fisheye web app clicking an IntelliJ icon will open a file in the IDE. It should be noted that this feature only appears to be available with Fisheye 2. I know because I’ve been missing it in Jira Studio, which still uses the 1.6 version of Fisheye.

Crucible

This is the one integration I’ve used the least so far, primarily because I don’t have Crucible installed locally for testing and again it seems a lot of the power of the integration is only available with version 2. The documentation certainly seems to suggest more rich functionality than I’ve found available anyhow. Fisheye and Crucible are actually bundled together for installation, so the Jira Studio version appears also restricted to the 1.6 version – for the time being at least. Mostly the Crucible integration is convenient because it provides messaging when reviews are assigned or commented.

Documentation

To be perfectly honest, I didn’t even look for these until writing this blog post. Configuring and using the plugin is very straightforward, provided you’re familiar with using these Atlassian tools at least. Nevertheless, I did discover a few additional bonuses and as usual the docs are both complete and up to date.

Overall

Really the point of using this plugin is to significantly reduce context switching; as much as possible your work is concentrated in one interface, and for the vast majority of cases you only need one piece of software running to get the job done. Where context switching is inevitable, this software tries to make it as “one-click” as possible. The end result is to put the power of your Atlassian products front and center in the IDE, where us developer types spend most of our working lives. Now, if only Jira Studio gets updated to the latest available software versions, because I’m dying to try out side-by-side diffs for Crucible reviews in IntelliJ!

Anyhow, if you use Atlassian tools the Connector is well worth checking out. And you Eclipse users aren’t left in the dark either. I can’t vouch for it’s quality, but there is an equivalent plugin for Eclipse available as well.

[Show as slideshow]

[View with PicLens]

Related posts:

1. Atlassian: Here Be Dragons
2. Griffon support in latest Intellij EAP
3. Thanks for the shirt Atlassian!

Since neither Grails nor Git are by default supported by Bamboo, I grabbed a couple of plugins to enable my home continuous integration system. Bamboo has a very sensible plugin model that allows for adding new capabilites with only a jar file in the right place and a server restart, and a fairly rich library of plugins. It’s also encouraging to see a company that is committed to eating their own dog food – recently they’ve moved their plugin resources to Jira studio as you can see on the Grails plugin home page. This gives you as the consumer of the software access to the wiki’d documentation, any open issues, and even visibility into when source code changes are committed. I’m assuming that last is subject to whether or not the plugin source code is open source or not, but still – pretty nifty.

The Grails plugin instructions speak for themselves in the 3 screen-shots on the one and only wiki page. Anything else you need to know is summarized in a one liner on the “Builder” tab when you select the Grails builder: “Use a new line to seperate Grails commands.” Gotta love clear, simple instructions. Drop the plugin jar into $BAMBOO_INSTALL_DIR/webapp/WEB-INF/lib, restart Bamboo and configure a new builder for Grails. Took a couple of minutes and knowing where my Grails install was located.

A quick Google for “Bamboo git plugin” led to a bit of a hypertext chase that eventually ended up here. Looks like this particular plugin has passed through the hands of at least a couple of maintainers, but so far it’s worked exactly as advertised. And again, loving the dog food analogy, it’s nice to see a project enabling Git hosted on github. Thanks very much to Kristian Rosenvold for running with the ball on this one! Again, drop the jar into $BAMBOO_INSTALL_DIR/webapp/WEB-INF/lib and restart Bamboo. When creating a plan you will now have Git as a choice for a Source Repository. In my case I’m just using a plain file repository that resides on the build box, but it should work just as well with a remote repository.

Setting up the Grails targets is similarly straightforward. Thanks to this article, which describes the Grails setup on Hudson, and reminded me about the –non-interactive flag since obviously the build server isn’t going to be able to interact with the console. I’m also using a couple of Grails plugins to provide static source code analysis so my parameters also include -coverage and a call to the codenarc script.

I had a little trepidation about how this would all turn out after reading this blog post, but I’ve had much better results so far in my personal experience. It’s entirely possible that the key differentiator is wrapping Grails with Maven. It’s definitely not perfect, but it is getting better all the time. Hopefully you have better luck in the future Neil!

[Show as slideshow]

[View with PicLens]

Related posts:

1. Jira Grails Plugin
2. Developing Faster with the Atlassian IntelliJ Connector
3. Gource Visualizations of the Groovy/Grails/Griffon Projects

Nothing terribly complicated going on for this plugin. Aside from the XMLRPC library and one more jar it depends upon there’s a service which implements calls for all of the methods on the XmlRpcService interface and a ‘helper’ class that makes using it a little easier(removes the need to pass the host name into each method). And any controller injected with the service gets a withJira(hostname, Closure) method which wraps the ‘helper’ class. This might not be the optimal way to do things, but I was looking for some better experience with MOP’ing in Groovy along with this little project so it worked out perfectly for me.

The method added to Controller classes just creates a ‘helper’ and sets it as the delegate for the closure.

        cClass.metaClass.withJira = {String hostname, Closure closure ->
            def helper = delegate.jiraXmlRpcService.createHelper(hostname)
            closure.setDelegate(helper)
            closure.setResolveStrategy(Closure.DELEGATE_FIRST)
            closure()
        }

Calling the withJira method looks like this, along with minimal exception handling:

            try
            {
                def projects, priorities, serverInfo
                withJira(jiraInstance.baseUrl) {
                    def token = login(jiraInstance.userName, jiraInstance.password)
                    serverInfo = getServerInfo(token)
                    priorities = getPriorities(token)
                    projects = getProjectsNoSchemes(token)
                    logout(token)
                }
                [jiraInstance: jiraInstance, projects: projects, priorities: priorities, serverInfo: serverInfo]
            }
            catch (e)
            {
                flash.message = "Failed to load data from ${jiraInstance.baseUrl}"
                redirect(action: "list")
            }

The ‘helper’ class itself represents an experiment with the Groovy ‘methodMissing’ behaviour. The idea is to store the ‘hostname’ for a series of calls against the stateless service and add that as the first parameter for all wrapped methods. It was simple and quick, but right off the bat you lose the ability to use IDE syntax completion support on this object. I thought another possibility here would be to use the @Delegate annotation on the service and/or Closure currying to add the additional ‘hostname’ parameter to methods.

class JiraXmlRpcServiceHelper
{
    def hostname
    def JiraXmlRpcService service

    def methodMissing(String name, args)
    {
        assert hostname && service
        def method = service.metaClass.methods.find {it.name == name}
        if(!method)
        {
            throw new NotImplementedException("The $name method is not implemented for ${this.getClass()}")
        }

        def newArgs = [hostname]
        args.each{newArgs << it}
        return method.invoke(service, newArgs as Object[])
    }
}

This plugin works with Grails 1.2.0.RC1 and represents about 8 hours of work all told – and a lot of fun to make! Jira 4 is not too shappy either, especially with the GreenHopper plugin. But that’s a post for another day.

A special thank you to Grails in Action and this article by Ted Naleid – both were extremely helpful putting this together. If you care to download it and take a spin here it is. Feedback is always welcome!

Related posts:

1. Bamboo, Grails and Git for Continuous Integration
2. A Groovy/Gradle JSLint Plugin
3. Grails-UI DataTable using XML for a model

First off, dealing with a RESTful call was about as simple as I’ve ever seen. This is the entire code that deals with creating the connection, authenticating, executing a GET, and parsing the returned XML into a ‘data’ property on the response.

    private withFisheye(String url, Map args) {
        withRest(uri: url) {
            auth.basic userName, password
            return get(query: args)
        }
    }

Getting XML using Andres’ plugin is extremely simple and we can achieve some pretty nice visualizations of the resulting data very easily as well. In particular I wanted to share how to use an XML response as a backing model for DataTable. The excellent examples provided by Matthew Taylor on his blog seemed to concentrate on using GORM to load and sort domain objects to utilize as data models. When using XML as an alternative way to represent the data, and using RESTful calls to populate that data, the available sorting options on a DataTable weren’t able to function properly without a little extra help.

Consider an list of XML elements like this, which represents a single review in Crucible.

<reviewdata>
    <allowreviewerstojoin>false</allowreviewerstojoin>
    <author>
        <displayname>Kelly Robinson</displayname>
        <username>TheKaptain</username>
    </author>
    <closedate>20010101T00::00.0000000</closedate>
    <createdate>20010101T00::00.0000000</createdate>
    <creator>
        <displayname>Kelly Robinson</displayname>
        <username>TheKaptain</username>
    </creator>
    <description>
        Test review
    </description>
    <moderator>
        <displayname>Kelly Robinson</displayname>
        <username>TheKaptain</username>
    </moderator>
    <name>
        Test review
    </name>
    <permaid>
        <id>CR1</id>
    </permaid>
    <projectkey>CR</projectkey>
    <state>Closed</state>
    <summary>
      Test review
    </summary>
</reviewdata>

You can leverage this list as a DataTable model by extracting specific elements from the XML, and providing a sorting mechanism based on dynamic map value lookups.

    private def createReviewDataJson(HttpServletResponse response, Map params, reviews) {
        def list = []
        response.setHeader("Cache-Control", "no-store")
       //build a List of Maps, one for each row in the DataTable
        reviews.reviewData.each {
            list << [
                    id: it.permaId.id.text(),
                    author: it.author.displayName.text(),
                    creator: it.creator.displayName.text(),
                    moderator: it.moderator.displayName.text(),
                    description: it.description.text(),
                    state: it.state.text()
            ]
        }
       //sort by the 'order' and 'sort' parameters passed in by DataTable
        switch (params.order) {
            case 'asc':
                list.sort { it."${params.sort}" } //sort by value where key == params.sort
                break
            case 'desc':
                list.sort {a, b -> b."${params.sort}" <=> a."${params.sort}" } //reverse sort by value
                break
        }
       //the entire model
        def data = [totalRecords: list.size(), results: list]
        render data as JSON
    }

This model can then be rendered using the tag. Note that this is pretty much a direct copy of a provided example, nothing fancy here.

<gui:datatable id="statDataTable" draggablecolumns="true" columndefs="[
        [id:'id', sortable:true, resizeable:true],
        [author:'author', sortable:true, resizeable:true],
        [creator:'creator', sortable:true, resizeable:true],
        [moderator:'moderator',  sortable:true, resizeable:true],
        [description:'description', sortable:true, resizeable:true, formatter:'textarea'],
        [state:'state', sortable:true, resizeable:true]
    ]" paginatorconfig="[
        template:'{PreviousPageLink} {PageLinks} {NextPageLink} {CurrentPageReport}',
        pageReportTemplate:'{totalRecords} total records'
    ]" sortedby="id" controller="fisheye" action="${action}" resultslist="results" rowsperpage="10">

So for very little work you get a sortable, paginated DataTable, complete with column resizing and dragging. The DataTable is also being rendered using a template, allowing it to be used arbitrarily by controller methods that populate the model with different reviews. Pretty cool if you ask me. I also used the same backing XML model to drive some PieCharts, but that’s perhaps a topic for another post.

Related posts:

1. A Grails App Demoing the StackExchange API
2. Groovy reverse map sort done easy
3. Jira Grails Plugin

DISCLAIMER: yes, this is heavily geared towards(but not exclusive to) Groovy-esque sources. What can I say – it’s where I spend most of my time.

Google… in General

If you want to find something – well let’s just say any service that is so pervasive it becomes a verb in the language might be useful.  Learning how to harness the power of the Google architecture can greatly enhance your learning experience. And I can’t see myself Bing’ing anytime soon.

1. Google Search: Knowing and using the Google search syntax properly can be a very powerful tool for finding specific tech-geekie knowledge.
2. Google Reader: Listening to the right content can save you a lot of time when it comes to getting the most out of your code. Even if you don’t read it everyday, combined with Gears and searchability this provides another tool in the fight against techno-ignorance that doesn’t rely on an internet connection.
3. Google Mail: I combine mailing list subscriptions with filters to automatically organize content. Incoming messages from lists are archived and labeled accordingly by filter rules. With Gears installed I’ve got an off-line searchable database of grassroots questions and answers, similar to what an on-line service like MarkMail provides. It’s hard to be the ongoing discussion of community members sharing their best tips, tricks and gotchas.
4. Google code: A great place to find open source projects that can assist you at work and provide valuable  learning materials. And yes, the link targets Groovy .

Aggregators

Some kind people do most of the work for you – taking themed content and putting it all together in one place.

1. DZone: One of my favorite sources of  techie style news.
2. GroovyBlogs: A great example of ‘eating your own dog food’, this is a Grails powered site courtesy of one of the authors of Grails in Action. Most of the Groovy related blog articles I read come from this source.
3. Grails Tutorials: A nice collection of tutorial articles related to Grails and Groovy.
4. GR8Forums: Brand new, this site has the potential to be a great discussion spot.

Community Sharing

There are certain places that encourage community and knowledge sharing more than others.

1. Groovy Console in The Cloud: This is an amazing example of an application exposing a Groovy console on the Google AppEngine, complete with community support for running, saving and commenting example code.  Since the code is freely available, there’s also already a Spock console here in the cloud forked/cloned from it.
2. Github and Gists: More places to share code in project and/or snippet form.
3. StackOverflow: A community effort to put together almost 300,000(and rising) questions and answers related to programming. If you have a question to ask, head over here – chances are someone else has already given an answer. It really is impressive how well this still evolving site functions.
4. Podcasts: JavaPosse and the Grails podcast are on top of my list and usually get listened to during my commute to work.There are hundreds of tech related podcasts out there; pick one or two and give them a listen,  you won’t regret it.
5. mrhaki : OK, this guy gets special mention just for busting out code examples for pretty much every Groovy feature you can possibly imagine. Seriously the guy posts 20+ times a month on average.

Home Pages

These aren’t necessarily up to date at all times, but are great places to start looking for generalized knowledge and additional resource material.

1. Groovy: Pay particular attention to the ‘Cookbook Examples’ and the ‘Modules’ available to quickly add functionality.
2. Grails: A particularly rich and well organized site – with the latest update it’s also very pretty.
3. Griffon: The builder documentation linked from here, combined with the example scripts included with SwingPad, get you up to speed quickly on all of the buildery goodness available in Griffon.

Useful and Inspiring

These are resources I use to step out of the box and to remind myself that it’s not only in elegant code that geekiness lies.

1. Lifehacker: I get into trouble a lot for this one; in my house whenever someone asks me “How do I do {fill in the blank}?” I invariably respond with “Well what does Lifehacker say?” My personal favorite is the bundle wrapping method. With a nice mix of techie and common sense goodness, I love to follow this site.
2. Make magazine: In need of a DIY project to fill up the weekend? From the Minty Boost for a $20 portable USB charger to robots this place takes geeking out entirely to the next level.
3. Jonathon Coulton: With eye-popping geekiness, Jonathon brings us such wonderful classics as “Code Monkey” and “Re Your Brains” – and under a Creatives Commons license as well!

Twitter

Use with caution. More than any other source of data, this one can end up being seriously distracting. I’m careful about who I listen to, while simultaneously trying to remind myself that nobody cares what I had for breakfast or how much I enjoyed it. Have you tried Twitter yet? Not as easy as it sounds buster, believe you me. Just wait and see. If you can keep yourself from jumping every time a new Tweet lands at your desktop, this can be the freshest, fastest way to satisfy your tech cravings.

Books

OK, so these aren’t free, but if you want to jumpstart your knowledge on a particular piece of technology, software or framework, picking up a recent book on the subject can truly help. I try to add a new book to the library every month, but the hard part is really finding the time to read and apply the new knowledge.

I don’t expect that these suggestions are for everyone, but hopefully a few of you out there in the interwebs will find some of them helpful. And feel free to share what works for you if I’ve missed anything.

Related posts:

1. Gource Visualizations of the Groovy/Grails/Griffon Projects
2. A Grails App Demoing the StackExchange API
3. A One Day Griffon Application/Presentation

Links on the IntelliJ site:

1. 1. The main documentation page
2. 2. Demos and tutorials including a couple of new Groovy support demonstrations
3. 3. 25 things you can do with IntelliJ 8 you can’t do with 7
4. 4. Mac Keymap reference
5. 5. Windows/Linux keymap reference
6. 6. The Jetbrains IntelliJ blog. A great way of getting tips from the guys that wrote it, and keeping up to date with improvements.

DZone: Intellij in 7 pages

1. 7. The DZone refcard for Intellij

My personal faves

1. 8. Command Shift-A to bring up a search window for actions. This one I think of as Quicksilver for my IDE.
2. 9. Alt-Enter to trigger intentions. Problem with your code? Let the IDE suggest a refactor to correct it.
3. 10. Ctrl-n for auto-generation of Java code. Getter and setter boilerplate getting you down(and you can’t switch from Java to Groovy)? Want a nice compact toString() on a class with 20 member variables? Let the IDE do the heavy lifting.
4. 11. The Javadoc Sync plugin. This goes well with #10 to javadoc all those getters and setters auto-magically.

Add logging using the debugger

1. 12. Printing to the console is a basic tool for debugging code. Everybody’s done it – because it’s easy and it works. But you often come across scenarios that disallow this quick and satisfying hackish behaviour. Namely when you are debugging into code in a library, this is not necessarily an easy option. Fortunately IntelliJ provides a nice easy way to add console logging through the debugger. You can access the breakpoint configuration dialog either by right clicking on an existing line breakpoint and selecting ‘Properties’ or by pressing Command Shift-F8 from the Debug view. From there you configure your line or Exception breakpoint with a ‘Suspend policy’ of ‘None’ and check the boxes under ‘Actions’ to enable logging. A full description of the features can be found here.

   I find this especially handy when there’s a problem iterating over a Collection and only one or some of the items in that Collection lead to an error condition during processing. Using this strategy I can provide context as to which cases passed and which failed without having to stop at a bunch of breakpoints and inspect the variables on the stack; I can just concentrate on the failure point and look back at the console output to compare against previous invocations.
   Here’s a couple of screencaps to show configuration for logging the size of a list on a line breakpoint. Note that the Groovy requires a little bit of extra magic, since the debugger gets passed a Reference object instead of the raw List.

[Show as slideshow]

[View with PicLens]

Bonus from the Community

1. 13. Grails returning the favor for the great IntelliJ support.

How about you?

1. 14. Do you know any other good places to learn about IntelliJ and how to get the most out of it? Please don’t keep it to yourself! I managed to line up a baker’s dozen, now you’re on the hook for number 14 smart guy.

Related posts:

1. Griffon support in latest Intellij EAP
2. Developing Faster with the Atlassian IntelliJ Connector
3. My favorite new Groovy trick

It appeared on the JetBrains blogroll a couple of weeks ago, and indeed may have showed up in an earlier release, but today was the first time I saw it in action. I couldn’t find anything about this new feature mentioned explicitly in the release notes but sure enough, it’s there. Given the similar project structure between Grails and Griffon, and the first class Grails support already available in IntelliJ, it’s really not too hard to see how this platform is in an ideal position to expand Griffon support. Beyond that the general Groovy support seems to get better in every release. The EAP is free to try for any holder of an IntelliJ 8.x license and seems to be pretty stable despite the disclaimers – I highly recommend taking it for a spin, especially if you’re already using this IDE. You get properly configured source directories and dependency paths, access to Griffon’s command line scripts, and even that awesome new Griffon icon shown to mark out the project. What more could you ask for?

JetBrains was beaten to the punch by a NetBeans plugin for Griffon that was released in its initial version before this year’s Java One conference. I’m not a NetBeans user myself, but I am a frequent reader of Geertjan Wielenga’s blog – he’s published some great Groovy examples. Even the Eclipse community has finally gotten around to putting out some real Groovy support, largely due to SpringSource‘s commitment.

Hopefully their recent acquisition by VMWare won’t distract them from developing it too much

Regardless of which development environment you feel most comfortable with, there’s no questioning this is a great time to be a Groovy/Grails/Griffon developer so enjoy!

Related posts:

1. My Favorite IntelliJ Resources, Tips and Tricks
2. Developing Faster with the Atlassian IntelliJ Connector
3. A One Day Griffon Application/Presentation

I’ve experimented a bit with Griffon a bit lately, but still being somewhat of a Groovy noob, I don’t think that the full impact hit me until I started reading the book. Maybe part of the problem is not that it’s hard to understand, but that it’s hard to believe that it’s so easy.

A very clearly defined way of separating the classic MVC. Injection of views, models, controllers – all available by convention not by annotation, xml configuration or even having to a refer to a component by name. The transparent access to a variety of builder actions through plugins makes a large toolset available with little or no cost. Clear architectural boundaries exist that guide you to where your code should be developed. The Griffon framework, created with gracious acknowledgement to its forerunner Grails strives to do one thing above all – make Swing easy.

The power and versatility of Swing has always been obvious to me. The ‘magic sauce’ that makes large scale Java Swing applications behave in any sane way has been a little more hazy. The advent of SwingWorker and other enhancements to the Swing toolset and the availability of better documentation have certainly made the landscape a lot more tolerable, but at the end of the day, it’s still hard to even find good examples of large Swing apps to use as a guideline(well at least it has been for me.) On the other side of the spectrum, I’m not sure there IS such a thing as a small Swing app. The amount of boilerplate code required is cumbersame, to say the least, and between anonymous inner classes for actions/listeners and correct handling of business logic and the EDT by the time you’ve finished doing anything moderately significant you’re already a couple 1000 lines in.

Griffon takes all that and hides it behind a curtain. Expanding on the already powerful SwingBuilder capabilities, it provides a quick and easy way to develop complex Swing applications. Utilizing @Binding to provide easy view/model interaction and baking the Observer pattern right into the framework make it beyond simple to deal with GUI events. And the pattern for dealing with EDT issues couldn’t be much more straightforward.

doOutside {
.... do whatever you need to do off of the EDT
doLater { ... come back to the EDT when you're done to update widgets }
}

I’m pretty sure that’s an easy enough pattern that I will never again forget the cost of doing… well pretty much anything that takes +1 second while blocking the EDT.

Personally, I’ve run into a couple of unexpected results when trying to utilize the webstart version of the application, but other than that everything has worked exactly as advertised. And at the end of the day I’m willing to chalk that up to my misuse of the system. I’ll tell you for sure when I get to that chapter of the book. Which will probably be about 2 days after the authors publish it.

So far my impression of the pre-release chapters of the book are pretty good – well written, clear and above all – the code samples work. Kudos to the authors Andres Almiray, Danno Ferrin and Geertjan Wielenga.  Look forward to the rest of the book boys, and to writing some new Swing apps with Griffon!

Related posts:

1. VIJUG Griffon/Groovy Presentation
2. SwingSet on Griffon
3. Griffon SwingX Fest testing

I got a chance to work with the brand new Griffon framework and must say – the combination of clear MVC architecture, Grails style convention over configuration and already powerful plugin selection make it pretty sexy.

The early support for cobertura code coverage and fest GUI testing are both appealing to any developer that appreciates the need for testing your application.  I’m still undecided on the Grails-like adoption of storing project information in a “.griffon” folder in the user directory and completely outside of the actual project directory structure. With luck, future versions will allow for incorporating maven to handle dependency management and get me past my FUD on that one, something that the latest Grails supports. I haven’t yet tried that new feature out in Grails out so I’m not entirely sure how well it works, but the docs say that there is a provided archetype and that all of the familiar Grails targets are mirrored in the maven goals.

Being able to add additional Groovy style builders as plugins is about as transparent as it gets – install the plugin and you can immediately incorporate that builder anywhere in the application.  The only builder component set that I have had a chance to work with previously is SwingX, but anyone who’s had the opportunity to use a JXTable in place of the vanilla JTable can immediately see the advantage! And the JDirectoryChooser from l2fprod is a powerful alternative to the Swing built-in JFileChooser.

The crown jewel so far however seems to be  the wizard plugin. This addresses what is  a very common scenario in any process related application:

• collect User input in a series of steps
• validate the input at each step
• allow the User  to go back and review or change any inputs
• apply all of the input to an underlying business process
• provide feedback as to the result

The wizard framework worked pretty much as advertised right out of the box and, although the project seems to have stalled (couldn’t seem to  find any updates since mid-2008) , when integrated so well with Griffon it seems a very good candidate for building lightweight applications – installers in particular jump to mind.

Any way you look at it – for a project as newly arrived as Griffon, it’s already promising to be a very powerful enabler. Thanks to Andres Almiray and everyone else involved in the project. I look forward to using Griffon more in the future.

Related posts:

1. A One Day Griffon Application/Presentation
2. Playing with the new Grails :)
3. SwingSet on Griffon