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!

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.

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!

[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

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!

[Show as slideshow]

[View with PicLens]

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!

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