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.

[View with PicLens]

Tweet This Post

Related posts:

1. Atlassian: Here Be Dragons
2. Griffon support in latest Intellij EAP
3. Bamboo, Grails and Git for Continuous Integration

The slideware plugin provides a framework for creating presentations with a little twist – you can execute code live from the presentation software. If you’ve ever given a presentation about programming you probably are fully aware of the transition from presentation software to your preferred environment for demonstrating code samples. Well, now you can stay entirely within the same application, editing and running code live.

The plugin itself isn’t available from the Griffon repository but source code and a built 0.2 version can be found on github. Considering both the youth of the plugin and the beta status of the framework, it worked impressively well AND had a rich feature set. All of the expected “powerpoint” features are there: themes, layout control, styling, slide transitions and export are all pretty easy to incorporate and configure. The code editor view also works very well. A great variety of additional plugins are harnessed to put all the pieces together and as a result building one of these applications is a great way to tour the platform.

Theming

Applying a theme to the presentation is simply selecting a Java Look and Feel to apply in Initialize.groovy. The Substance jar is included with the plugin so I test drove a few of the nice setups in there and finally settled on the SubstanceMagmaLookAndFeel. There is definitely a wide variety of L&F’s to choose from in that bundle alone and, although I haven’t done it myself, they seem pretty tweakable as well. Plus any old L&F should plug in nicely, I would imagine.

//Initialize.groovy
SwingBuilder.lookAndFeel('org.jvnet.substance.skin.SubstanceMagmaLookAndFeel',
       'mac', 'nimbus', 'gtk', ['metal', [boldFonts: false]])

Layout

Controlling the page composition is a standard Swing Layout or, in the case of the default slide you get with the included “create-slide” script, a MigLayout. Framing the standard variety of slides is very simple. Bulleted pages, title slides, code slides and custom layouts are very easy to accomplish. I don’t have a lot of experience using this particular layout but the presentations Andres has made available on github have a good diversity of examples of how they look in practice.

//the default create-slide generated template
import net.miginfocom.swing.MigLayout

slide(id: "slide0", layout: new MigLayout("fill","[center]","[center]")) {
    label("Insert your text here")
}

Styling

Styling is supplied by the css plugin, on which slideware has a dependency. The default style.css file sets out just some reasonable defaults for the fonts used in different parts of the app, and I didn’t see any real need to fiddle with it. Especially happy to see the nice monospace code font. On a totally related note I recently installed the Inconsolata monospace font to try for development and I’ve been very happy seeing it in my editor, but it’s still nice to see this kind of polish applied to the presentation. The code editor view even includes syntax highlighting! More on that coming right up…

Slide Transitions

Moving between slides with style is the responsibility of the transitions plugin. You can see see all of the animations this plugin enables over here at this page describing Transitions and Transition2Ds. Pretty slick stuff and defined as simply as a parameter to each “slide” node in a script.

slide(id: "slide3", layout: new MigLayout("fill","3%[center]3%","3%[center]3%"),
        title: "Junit3",
        transition: new FlurryTransition2D(Transition2D.OUT)) {
    scrollPane(constraints: "grow") {
        widget(createEditor(text: script))
    }
}

Code Editor

Code slides embed an editable widget and allow for composing and executing Groovy scripts or classes of arbitrary complexity. You can execute the code with a keyboard shortcut and a window will open displaying the console output. The code itself is executed through a GroovyShell, enabling pretty much anything you might want to do. If you have an internet connection and the required repositories configured, Grapes simplifies packaging the dependencies for the application as your code samples can directly Grab the jars they need. Basically, the first time you execute a code slide you’ll have to put up with a small pause while Ivy downloads to your local repository, unless of course the required dependencies are already there. In my case I changed strategies from including jars in the application lib directory to a Grapes approach and I think it’s a better way to go.

I was surprised to find that the editor even included undo functionality. It’s definitely not close to a full blown IDE, and there’s absolutely no reason that it should be. For the task of demoing simple code examples it’s more than up to the task, even to the point of maintaining your edits between slide transitions, allowing you to move back and forth through the slide deck without any state problems.

Export

The application includes a “Print” feature which iterates through the entire slide deck and renders it to a pdf. Distribution of one of these presentations is really very easy, including the ability to create installers for all major platforms simply by adding the packaging plugin.

Test Application

The test app I built while looking into this is pretty simple. It’s got a title slide, a bullet slide and 4 code slides. The code simply demonstrates how you can create test classes and make assertions for Junit 3(with GroovyTestCase), Junit 4 and TestNG. GroovyShell recognizes all 3 of these test files by interface or annotation and executes them appropriately. In each case the console output of the test framework is the result, including the new Spock inspired ascii art assert failure renderings. The Test result files are also written to disk, and that TestNG html output is what I’m used to looking at anyhow. Show me the Green!

The last code slide is just a slightly updated version of an example script on the Grapes page, using the current version of Google Collections and intentionally introducing a failure- mostly just to show off that new assert rendering I mentioned a moment ago. VERY helpful at highlighting the exact nature of a failure. It also encourages me to pay more attention to how I name variables, something I’m sure every developer that has ever worked with me will cheer at. Man, I suck at naming things.

I also developed a brute force test that loads each slide and executes scripts if finds embedded there. Failures are hard to detect since the direct output is simply a text block, but some fairly simple regex’s applied to the output make me at least moderately confident that the code won’t fail at show time.

Overall Impression

It took a couple of afternoons(six hours or so total) to download the source code from github, explore it, create a simple presentation and document the experience. I won’t begin to suggest that I’m fully aware of all the details happening behind the scenes, but the end user experience is pretty fluid: create a slide, tailor the layout, add content and then repeat. The included examples were more than enough documentation on how to hit the ground running. The plugin code itself is a great example of the MVC nature of Griffon, not a whole lot of code, but a great deal of power and expressability. There were a couple of glitches happening in the background, mostly just logging to the console with no visible effect to the application, but overall it functioned as well as (not) advertised. For publicly unreleased software it was an absolute pleasure to work with and I plan on continuing with the development of this particular presentation.

Everything you need to build and run this stuff yourself is publicly available. In my case, Griffon generally has a recent Macport available for both the released(griffon @0.2.1) and development versions(griffon-devel @0.3-BETA-2). Switching versions is relatively painless and, for applications this simple, testing out upgrades is basically just going through the presentation once in a functional test. Versions for other platforms can be downloaded from the Griffon download page.

Deliverables

Source code for the sample application is available on github here. Please just leave a comment on this page if you have any problems running it.

Here’s the pdf produced by the application ‘Print’ feature: Groovy Testing Presentation (44)

And if you don’t feel like downloading anything, here’s how it all looks in pretty pictures.

[View with PicLens]

Tweet This Post

Related posts:

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

Actually I’ve used Gliffy in Confluence before, and it’s come in handy more than once or twice. But between Balsamiq and OmniGraffle I’m already well equipped to cover up the fact that my artistic abilities lie somewhere below drawing stick men. TaskDock has however been installed and set up to nag me via email when I am getting behind schedule. Next will be Customware’s scaffolding and reporting plugins. The scaffolding capabilities make dealing with tables in Confluence a breeze – almost(but not quite) enough to make me abandon the wiki editor completely. Why take my word for it when you can just watch the video?

Anyhow, so far I’m very happy with the software and how it’s already helped me organize projects at home better. The t-shirt is just a nice bonus.

Tweet This Post

Related posts:

1. Atlassian: Here Be Dragons
2. Developing Faster with the Atlassian IntelliJ Connector
3. Bamboo, Grails and Git for Continuous Integration

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!

[View with PicLens]

Tweet This Post

Related posts:

1. Jira Grails Plugin
2. Developing Faster with the Atlassian IntelliJ Connector
3. Thanks for the shirt Atlassian!

The Atlassian Toolbox

Jira is the cornerstone of the stack and, with the addition of the ‘Agile’ GreenHopper plugin, is an ideal tool for tying together issue tracking and project planning in one easy to work with bundle. Crucible and Fisheye provide peer review and repository browsing. The Confluence wiki provides a great framework for organizing and sharing knowledge. Bamboo is an extremely versatile continuous integration platform. Crowd provides SSO and identity management. And they all can link together nicely to provide consolidated views spanning the entire stack.

Here Be Dragons

Late in 2009 Atlassian started a new marketing campaign geared towards smaller deployments: $60 to purchase 10 user licenses for the entire software stack, including 30 day trial licenses with support. Previously some of the applications were available for personal use(2 or 3 Users only) at no cost, and indeed I have a Confluence install I’ve been using for the last year, but this deal makes the entire stack available at what is really a very reasonable price. And they even include a fun, if slightly corny, tutorial which guides you through installing and configuring all of the applications to link them together. So here’s my experience ‘Slaying the Dragon’.

The very first thing I discovered was that my years old Intel iMac with 1GB of memory just wasn’t going to cut it. The recommendation is for 2GB of memory and “No other applications running — just the operating system, JAVA, PostgreSQL and the Atlassian applications” so I of course took that as an opportunity to ask Santa for a memory upgrade.

Ten days later, with 4GB of brand new RAM installed I got much further than the SLOW grind that was Crowd + Jira + Confluence + iTunes fighting with each other over 1 gig of memory(shudder). Aside from a couple of minor hiccups, everything installed without hassle and the instructions were nothing short of spectacular. I did have to make some tweaks to the postgres database configuration upping the number of allowed connections; apparently this setup is more than a little connection hungry, tsk tsk. Crowd is the one application I’m least familiar with, and integrating with it seemed to be the most actual ‘work’ but hey – if manually copying around and modifying a couple of configuration files is the biggest hassle involved in providing SSO for 5 enterprise apps, I think I can live with it.  I am probably going to have to bite the bullet and invest in a more practical server machine, but I’m pretty sure the 2010 budget can find room for at least one new computer.

Been There, Done That, Where’s my T-shirt?

I’ve already started to plan out milestones for the new year’s projects in Jira, so I guess I’m already committed to paying the $60 when my trial period expires. Especially when Atlassian is donating all proceeds to Room to Read. I get enterprise-ready software for cheap AND all the money goes to a good cause. Win-win in my books – and a great job by Atlassian(on both the software and the charitable good.) Did I mention they’re sending out free t-shirts to anyone who completes the challenge?

In the gallery below is a screen shot for the single Jira Dashboard view you end up with at the end of the exercise. It ties together activity from each of the applications into one homogeneous view, and each widget is color coded to represent where the data is being drawn from. If you’re looking for an affordable solution to help streamline your work at home or in a small development team, check it out!

[View with PicLens]

Tweet This Post

Related posts:

1. Thanks for the shirt Atlassian!
2. Developing Faster with the Atlassian IntelliJ Connector
3. Bamboo, Grails and Git for Continuous Integration

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!

Tweet This Post

Related posts:

1. Bamboo, Grails and Git for Continuous Integration
2. Grails-UI DataTable using XML for a model
3. Developing Faster with the Atlassian IntelliJ Connector

Groovy on the command line

The quickest and simplest way to run a Groovy Script or Class, command line arguments are automatically marshalled into an ‘args’ String array. Please note that due to a problem I’m having with my syntax highlighter plugin the process execution is shown here in single quotes; the actual code requires a GString(double quoted) in order to do the replacement for the inline variable. " THAT Wordpress!

//the script
myArgs = args
result = args.join(' ')
println result
println myArgs

//...and the test
    void testGroovyCall()
    {
        def proc = 'groovy $groovyScriptOne Hello World'.execute()
        proc.waitFor()
        def result = proc.text.split()
        assert result[0] == 'Hello'
        assert result[1] == 'World'
    }

GroovyShell

This is the basis of Groovy script execution. The GroovyShell allows for executing scripts, passing in a particular Binding context that allows for bi-directional communication between the script and the calling code. Parameters can be passed into the executing script in the Binding and results can be stored there to be returned to the calling context. GroovyShell also allows for running a class from the ‘main’ method, passing in String arguments. It will also execute implementers of Runnable and test files for JUnit or TestNG. Script text can also be declared inline and executed in the same way as files on disk. All in all, pretty bloody handy. Here’s a straightforward example of running a dirt simple Groovy script and inspecting the results. Note that this isn’t executable as shown, but I’ll provide the full source code on github for anyone who wants a closer look. Note that I’m also passing in an ‘out’ variable in the Binding, which effectively redirect System.out to a specified Writer implementation – a nice touch for inspecting output.

//the script
myArgs = args
result = args.join(' ')
println result
println myArgs

 //...and the test
    void testGroovyShell()
    {
        Binding binding = helper.createBinding()
        def shell = new GroovyShell(binding)
        shell.evaluate(new File(groovyScriptOne))
        helper.assertBinding(binding)
    }

//...and the Binding creation/assertion
     def static args = ['Hello', 'World'].asImmutable()
     /**
     * Create a Binding with a single parameter to be passed to scripts and an 'out' Writer to redirect console output.
     */
    private Binding createBinding()
    {
        Binding binding = new Binding()
        def sWriter = new StringWriter()
        def pWriter = new PrintWriter(sWriter)
        binding.setVariable ('args', new ArrayList(args))
        binding.setVariable ('out', pWriter)
        return binding
    }

    /**
     * Assert that the expected 'common' actions are done with the Binding by each of the use cases.
     * The original 'args' should be as expected.
     * A copy of 'args' should have been placed in the Binding during execution.
     * The 'result' should be the concatentation of 'args' separated by spaces.
     */
    private def assertBinding(Binding binding)
    {
        assert binding.variables.size() == 4
        assert binding.variables.args.value[0].toString() == args[0]
        assert binding.variables.args.value[1].toString() == args[1]
        assert binding.variables.result.value.toString() == args.join(' ')
        assert binding.variables.myArgs.value[0].toString() == args[0]
        assert binding.variables.myArgs.value[1].toString() == args[1]
    }

GroovyScriptEngine

The GroovyScriptEngine enables dynamically running Groovy sources located in a fixed set of content roots, complete with reloading modified scripts in between executions. Running a Groovy script this way is essentially the same as using GroovyShell.

    void testGroovyScriptEngine()
    {
        Binding binding = helper.createBinding()
        def gse = new GroovyScriptEngine(new File('.').toURL())
        gse.run(groovyScriptOne, binding)
        helper.assertBinding(binding)
    }

GroovyClassLoader

An extension to URLClassLoader that enables parsing Groovy sources into Class representations. Once a Class object is created, instances of the class can be created easily and either cast to a known type or manipulated through convention by use of the standard Groovy ‘invokeMethod’. This works equally well on Groovy and Java btw. Here’s an example of running a Java class using GroovyClassLoader. In this case the Java file has a field called ‘binding’ and implements a ‘run’ method.

    /**
     * Dynamically compile, instantiate, inspect and call methods on a POJO.
     */
    void testGroovyClassLoaderOnJava()
    {
        GroovyClassLoader loader = new GroovyClassLoader();
        Class javaClass = loader.parseClass(new File(javaFileOne));

        def groovyObject = javaClass.newInstance();
        def binding = helper.createBinding()
        groovyObject.binding = binding
        if(groovyObject.metaClass.respondsTo(groovyObject, 'run'))
        {
            groovyObject.invokeMethod('run', null);
            helper.assertBinding(binding)
        }
        if(groovyObject.metaClass.respondsTo(groovyObject, 'main'))
        {
            groovyObject.invokeMethod('main', new ArrayList(helper.args) as String[]);
        }
    }

(Groovy)Console

The Console can be embedded in Java or Groovy code to provide a dynamic interactive Swing environment. This is the same UI spawned from the command line invocation of ‘groovyConsole’. Internally it uses GroovyShell for actual execution, and so can do everything that GroovyShell can do – plus a couple of additions. For one, you can add jars and/or directories to the classpath used when executing your scripts.

The Best of Both Worlds – at Least for my use case

In actual practice these patterns can be used a lot more successfully by observing standard Java practices, like casting classes parsed using GroovyClassLoader to a known interface before interacting with them, or by using Classes to organize business logic inside of a Script that essentially functions as a ‘main’ method. This example defines two dependent internal classes, marshals parameters to them and then returns the results attached to the originally passed in Binding.

/**
 * Classes inside of a Script.
 */
class TestableClass
{
    Binding binding

    def run()
    {
        binding.with
        {
            setVariable('myArgs', getVariable('args'))
            setVariable('result', getVariable('args')?.join(' '))
        }
        return binding
    }
}

class TestableClass2
{
    Binding binding

    public TestableClass2(Binding binding)
    {
        this.binding = binding;
    }

    def run()
    {
        return new TestableClass(binding: binding).run()
    }
}

if (args)
{
    def internalBinding = new Binding()
    internalBinding.setVariable('args', new ArrayList(args))
    internalBinding = new TestableClass2(internalBinding).run()
    args = internalBinding.args
    myArgs = internalBinding.myArgs
    result = internalBinding.result  //return value from script
}
else
{
    println 'no args!!'
}

Summary of Groovy Execution Methods

Tweet This Post

Related posts:

1. Groovy CliBuilder with multiple arguments
2. A One Day Griffon Application/Presentation
3. Jira Grails Plugin

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.

Tweet This Post

Related posts:

1. Jira Grails Plugin
2. Groovy reverse map sort done easy
3. StreamingMarkupBuilder for Groovy-er xml

def map = [a:3, b:2, c:1]
map = map.sort {it.value}
assert map == [c:1, b:2, a:3]

Turns out doing a reverse sort on a Map by values is almost as easy.

def map = [a:1, b:2, c:3]
map = map.sort {a, b -> b.value <=> a.value}
assert map == [c:3, b:2, a:1]

Using the spaceship operator (‘< =>‘) you can define a very terse syntax for accessing ‘compareTo’, as long as the values in the map implement Comparable that is.
Nice!

Tweet This Post

Related posts:

1. Grails-UI DataTable using XML for a model
2. Griffon SwingX Fest testing
3. My favorite new Groovy trick

Back working with JBoss Seam today. And it seems I missed it too. Don't worry Grails, I still love you more #

RT @aalmiray: ♺ @pledbrook How to test your Grails scripts: http://tinyurl.com/ycsjwc8 we're so borrowing that for #griffon #

Out for lunch on the boss. Turns out hacking out awesome Groovy scripts has an added benefit #

Powered by Twitter Tools

Tweet This Post

Related posts:

1. Twitter Weekly Updates for 2009-09-07
2. Twitter Weekly Updates for 2009-09-28
3. Twitter Weekly Updates for 2009-05-03

@Rod_Phillips Royal Oak please #

Powered by Twitter Tools

Tweet This Post

Related posts:

1. Twitter Weekly Updates for 2009-09-07
2. Twitter Weekly Updates for 2009-08-31
3. Twitter Weekly Updates for 2009-08-31

Here’s a GroovyTestCase that exercises CliBuilder with multiple arguments.

package org.kar
import org.apache.commons.cli.Option
/**
 * Demonstrates usage of the CliBuilder with multiple arguments to create a List.
 */
class CliBuilderDemoTest
extends GroovyTestCase {
    /**
     * You can specify multiple arguments one at a time.
     */
    void testMultiOption() {
        CliBuilder cli = new CliBuilder()
        cli.with {
            a longOpt: 'arguments', args: 2, required: true, 'Two arguments'
        }
        def args = ['-a', 'arg1', '-a', 'arg2']
        def options = cli.parse(args)

        assert (options)
        assertEquals('First arg is available with the -a option. ', 'arg1', options.a)
        assertEquals('Should be two args, in order, available with the addition of an "s" to the option.',
                ['arg1', 'arg2'], options.as)
    }

    /**
     * You can specify multiple arguments together in a block, with a defined separator(in this case a comma).
     */
    void testMultiOptionWithSeparator() {
        CliBuilder cli = new CliBuilder()
        cli.with {
            a longOpt: 'arguments', args: 2, required: true, valueSeparator: ',' as char,
                    'Two arguments, separated by a comma'
        }
        def args = ['-a', 'arg1,arg2']
        def options = cli.parse(args)

        assert (options)
        assertEquals('First arg is available with the -a option. ', 'arg1', options.a)
        assertEquals('Should be two args, in order.', ['arg1', 'arg2'], options.as)
    }

    /**
     * You can also have any number of arguments by specifying UNLIMITED_VALUES.
     */
    void testUnlimitedArgs() {
        CliBuilder cli = new CliBuilder()
        cli.with {
            a longOpt: 'arguments', args: Option.UNLIMITED_VALUES, required: true, valueSeparator: ',' as char,
                    'Two arguments, separated by a comma'
        }
        def args = ['-a', 'arg1,arg2,arg3']
        def options = cli.parse(args)

        assert (options)
        assertEquals('First arg is available with the -a option. ', 'arg1', options.a)
        assertEquals('Should be a list of args, in order.', ['arg1', 'arg2', 'arg3'], options.as)

        def args2 = ['-a', 'argOnly']
        def options2 = cli.parse(args2)

        assert (options)
        assertEquals('First arg is available with the -a option.', 'argOnly', options2.a)
        assertEquals('Should be a list of args, with a single entry.', ['argOnly'], options2.as)

        def args3 = []
        //this will automagically print the usage string and any validation errors to System.out
        def options3 = cli.parse(args3)
        assertNull(options3)
    }
}

Anyhow, hope that the next guy finds this info useful – it certainly has made my recent work writing Groovy scripts much easier!

Tweet This Post

Related posts:

1. Different Flavors of Embedded Groovy in Java Apps or “How To Make your Java Groovier!”
2. Grails-UI DataTable using XML for a model
3. Using the TestNG DataProvider with Groovy

@aalmiray no worries. I've got a fair bit of experience already with jgoodies forms, can muddle my way through in the meantime in reply to aalmiray #

Upgrading maven, git, svn and Groovy in one line. Thank you #macports for making things so easy #

Powered by Twitter Tools

Tweet This Post

Related posts:

1. Twitter Weekly Updates for 2009-04-05
2. Twitter Weekly Updates for 2009-09-14
3. Twitter Weekly Updates for 2009-04-26

If only it were every morning RT @jstrachan: I love the smell of a brand new MacBook Pro in the morning… #

@mosabua @ajordens Burndown charts are where it's at man. Without Burnination there can be no progress #

Powered by Twitter Tools

Tweet This Post

Related posts:

1. Twitter Weekly Updates for 2009-08-24
2. Twitter Weekly Updates for 2009-09-07
3. Twitter Weekly Updates for 2009-09-28

Looks like a very nice day in Victoria is turning cold and rainy. Thankfully I got the dogs out for a great walk earlier #

Powered by Twitter Tools

Tweet This Post

Related posts:

1. Twitter Weekly Updates for 2009-05-10
2. Twitter Weekly Updates for 2009-03-29
3. Twitter Weekly Updates for 2009-09-28