Home

If you are interested in writing a plugin for JIRA, Confluence or any other Atlassian application, you have come to the right place. If you're interested in finding plugins to use in your Atlassian tools, you should check out our plugin library on http://plugins.atlassian.com.

Writing Atlassian Plugins

All you need to know about writing, testing and releasing a plugin with the Atlassian Plugin Framework. Read more.

Writing Atlassian Gadgets

How to write a gadget that will work on your JIRA dashboard or Confluence page. Read more.

Using Plugins

How to find the plugin you need and check its support policy. Read more.

Getting Involved

There are many ways you can contribute to and take part in the developer network, even if you have not (yet) written your own plugin. Read more.

Plugin Development Resources

Our early access program, documentation and other resources. Read more.

Atlassian Blogs » Developer (Software development and collaboration tools)
CodeCache is full. Compiler has been disabled. When I was timing how long it takes JIRA 5.0.1 to reach a steady state for GC & code compilation with JDK 1.6.0_26 for a GC tuning guide; I noticed a log message that I’d never seen before: 12Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled. Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize= This cache is a memory area separate from the JVM heap that contains all the JVM bytecode for a method compiled down to native code, each called an nmethod1. This is where the JIT compiled methods are kept. On server classed 64 bit VMs, the reserved cache size is 48 MB (Used to be 1 GB, see Bug 6245770). Once the compiler is switched off due to the Code Cache being full, it does not switch back on. Existing nmethods will continue to be used until they are flushed from the cache. As this was the first time I’d seen this interesting message, I decided to do some digging as I hadn’t encountered the VM code cache with previous research in to HotSpot garbage collection. Impact of the Code Cache being full is that JIT compilation is now off for the remainder of the JVM’s life. We don’t have any statistics as to the impact of this on long running performance; the impression that I have is that CPU utilisation & request service time would increase over long running VMs for code that could have been optimised. For a system that is over-committed on CPU resources the application throughput could decrease noticeably. The suspicion that I have here is that if I give the Code Cache some fatpants by increasing -XX:ReservedCodeCacheSize=, I’d just be delaying the problem. So I dug in to the HotSpot code to see if there was a way that the JVM can manage this for me. Turns out, there is; in the HotSpot source for jdk6 the following flag is available for product releases, -XX:+UseCodeCacheFlushing: 1product(bool, UseCodeCacheFlushing, false, "Attempt to clean the code cache before shutting off compiler") It is not on by default. So I turned this on, and I no longer observed the log message about the code cache being exhausted with the particular environment being used. I wanted to confirm that this was working as advertised, so I read through the HotSpot code to determine how the Code Cache flushes nmethods during default operation and when -XX:+UseCodeCacheFlushing is used. There is a way to infer when nmethods are flushed by interpreting the log messages printed with -XX:+PrintCompilation, the lines that are important are the ones where an nmethod has been made a zombie: 1552287 4320 made zombie org.ofbiz.core.entity.EntityExpr::makeWhereString (557 bytes) With -XX:+UseCodeCacheFlushing, what you would be looking for is a large group of these messages in quick succession, as it generally indicates the processing of older nmethods to be flushed from the code cache. As opposed to normal flushing due to class unloading or deoptimisation. This doesn’t give [...]
AtlasCamp EU Videos Now Online! For those who missed the event, the AtlasCamp Europe 2012 videos are now online. This AtlasCamp was our first ever developer event in Europe and it was a smashing success. Thanks for all who made it possible. Here are the talks: Keynote – Jean-Michel Lemieux, VP of Engineering, Atlassian All About the Marketplace — Jonathan Nolen, Director of Developer Relations, Atlassian Licensed to Sell: How to use Atlassian’s new Licensing API to Sell your Plugin on the Atlassian Marketplace — Ben Woskow, Integrations Developer, Atlassian Plugin Safety Check – How to Ensure Your Plugin Gets Approved — Penny Wyatt, QA Engineer Polyglot Plugin Programming — Stefan Sassen, Development Team Lead First Look: Remote Plugins for Atlassian Apps — Rich Manalang, Developer Advocate, Atlassian Better Front-End Development in Atlassian Plugins — Wojtek Seliga, JIRA Developer, Atlassian If you’ve never been to an AtlasCamp, put it on your list of events to attend this year. Our next one kicks off in September/October in Half Moon Bay, California. Be on the lookout for the announcement this summer.
My Hip New Workflow with HipChat I’m not a huge fan of most notifications, especially the ones that vie for my constant attention — like badge notifications on my iPhone. However, there is a time and place for focused and timely notifications that have increased my productivity. Many people who’ve never used HipChat before are quick to dismiss it as a simple group chat application. However, once you use it, it becomes apparent that it’s a lot more than a group chat app. One of my favorite features of HipChat is the ability to bring in relevant notifications into your team’s room. Here’s an example of a notification coming from JIRA: JIRA’s workflow engine is highly flexible and can be tuned to whatever process you want to support regardless if you’re managing issues, requests, or tasks. We built a JIRA plugin for HipChat that binds to JIRA’s workflow engine (using Post Functions) to allow JIRA project admins to subscribe to any workflow transitions they please. For example, you may not want to notify your team of every issue transition, but maybe just the ones marked with a high or blocker status. In our Developer Relations room, we find that notifications from Twitter and Zendesk are highly useful for responding to questions or comments by developers in our ecosystem. This is possible through a SAAS based integration service by Zapier. In other rooms, some teams like to see commit notifications from Bitbucket and Fisheye as well as build notifications from Bamboo… we have plugins for those too: I’ve seen other teams use HipChat notifications to alert them of new product orders/subscriptions that come in. This is all possible through HipChat’s simple REST API. Although, before you attempt to integrate something with HipChat, check to see if that integration already exists on HipChat’s catalog of existing integrations — all 38 of them! If the integration you’re looking for doesn’t exist, the REST API is as simple as… POST /v1/rooms/message?format=json&auth_token=token HTTP/1.1 Host: api.hipchat.com Content-Type: application/x-www-form-urlencoded Content-Length: 138 room_id=10&from=Alerts&message=A+new+user+signed+up These are just a few great productivity boosters you can use for your teams on HipChat. Of course, there’s also a fun aspect to HipChat including HipChat’s unconventional emoticons. What do you think? Could your team benefit from these type of features? If you use HipChat, care to share with us what you like to do with it, other than chat?
How Gliffy is managing the risk of re-writing their product in HTML5 This is a guest blog post by Chris Kolhardt, CEO and Founder of Gliffy, a tool that makes it easy to create, share, and collaborate on a wide range of diagrams. In this post Chris shares the process, risks, and rewards of migrating away from the outdated technology that powers the editor in Gliffy Confluence Plugin, a web based diagramming tool that makes it easy to insert UML, wireframes, network diagrams, flow charts, and more right into your Confluence pages. How many times have you looked at a code base and dreamt about how much better life would be if you could just start over from scratch and re-write that sucker? On the surface, a re-write sounds like the optimal solution to making your life easier and solving all sorts of problems. We find ourselves thinking this all the time, specifically: If I could only take the time to ditch this slow-to-compile Java code with Ruby on Rails, we’d be shipping features at 10x the speed A re-write will enable us to cast away all the crufty code we wrote while rushing to get our 1.0 built We understand the problem so much better now, a rewrite would enable us to create a new design that would be infinitely more manageable Re-writing software from scratch isn’t as awesome as it sounds The truth is, re-writing a large code-base is super risky. Joel On Software has a great write up about why you should never re-write code. Major highlights include: The production code you have today has been used, tested, and it works There is significant time and effort on the part of both a developer and the end users to get code into a working state The reason the production code you have today is ugly is because it evolved into that after years of taking into account all the bugs, new requirements, and edge cases that you couldn’t possibly have known about or thought about when that code was first typed in There is opportunity cost to taking the time to re-write a code base because that means for the duration of the re-write, no new features can be added to the software Flash helped make Gliffy successful, but has no future Ok, so re-writing software is super risky and fraught with danger, but what if the platform your product is based on might not be around in 5 years? This is the problem that Gliffy faces today. Back in 2005, we felt that the best technology available to us for creating a feature rich diagram editor in a web browser was OpenLaszlo, which is a XML based markup language that compiles into Flash byte code. By leveraging the rich drawing capabilities Flash offered, we were first to market with a web based diagramming product that was feature comparable and just as interactive as any comparable PC or OS X native diagramming product. This resulted in Gliffy becoming a profitable company without any outside financing, almost immediately. You want to be first to market, right? Yes, and no Being first to market can be a mixed [...]
Atlassian Devs Talking JIRA Mobile Connect on iDeveloper Live Podcast UPDATED: The recording of iDeveloper Live Episode 50 featuring JIRA Mobile Connect is now available for download and on iTunes. We launched JIRA Mobile Connect (JMC), a free library for JIRA that allows mobile developers to gather in-app feedback from their users, back in October 2011. Then, we introduced iPad compatibility and HockeyApp integration for JMC in January 2012, so that developers could seriously beta test their apps before releasing them to the wild. Now, our very own Nick Pellow, the original developer of JIRA Mobile Connect (JMC), and Josh Devenny, product manager for JMC, are being featured on iDeveloper Live, a podcast for OS X and iOS developers. Tune in on April 16, 2012 at 9:15am PST, to hear them discuss the origins of JIRA Mobile Connect and what the future holds in store for both JMC and JIRA. Alongside these two, Today Voice Notes app creator Stefan Nicolin will be chiming in on his own experiences using JIRA and JIRA Mobile Connect as a mobile app developer. You can listen to live audio 15 minutes before each podcast begins at http://ideveloper.tv:6996/ideveloperlive and ask your own questions during the show on IRC channel #ideveloperlive hosted on the FreeNode network. Check in to say hello, or to have Nick and Josh answer all your burning questions!