Your memory needs will likely vary based on the Atlassian host application that you’re working with. For instance, Atlassian recommend 2 GB of RAM as a minimum for running a small installation of Jira Server, while for running Confluence they recommend 6 GB of RAM.

These instructions were tested on a virtual machine with 4 GB of RAM and 2 processor cores available. While that seemed a bit pokey, it was manageable. That said, human attention tends to be significantly more expensive than RAM. Seasoned Atlassian plugin developers recommend 16 GB of RAM on your development computer if possible, particularly as you run more and more things to test and debug your application (IntelliJ, the Atlassian application, one to four web browsers, etc.).

A debugger, which lets you pause your code mid-execution, can be extraordinarily helpful for complex scripts. Let’s create a debug configuration for that.

That action should start the debugger and a window like this one should show up in the lower area of IDEA:

Okay, now that you’ve setup your debugger, what next?

One of the biggest benefits of writing your code in IDEA is that you can access the javadoc directly in the IDE instead of needing to go to the API’s documentation website.

If you have purchased a license from an Atlassian product, you will have access to the source download page.

Let’s create a new Groovy script to see this working.

Type userManager. and you will see the properties and methods available to be used.

The last step to have full access to the application API is to link your code to the application sources. In IDEA if you hold the Ctrl key (CMD in OSX) and click on a class name or method you will be redirected to the source file of the class. Try this for the UserManager class located at the end of line 4. You will see something like this:

The decompiler is great and will already give you a lot of information about the class, but you can go even further and see the whole implementation of it.

Since you probably have access to the sources of the application, download the version you are working with and unzip it.

If you click the Choose Sources link and select the folder that contains the application source, the source for the class will be shown, and the IDE will provide better parameter names and inline javadoc.

The scriptrunner parent pom sets a lot of default values for the versions of the libraries to be used when writing your scripts. Those default values can be changed if you are going to write scripts for a different version of the Atlassian applications. You can change them by editing the <properties> section of your pom.xml.

For example, to set the Jira version to 7.4.5, your properties block might look like:

You can similarly specify a product data version:

If you are writing a plugin for JIRA, you may require JIRA Software, or JIRA Service Desk. To do so, add additional configuration to the jira plugin, for example:

Note that for the above example to work you’ll want to define a <jira.servicedesk.application.version> property in the pom.xml file’s <properties> block as described in Customise product versions.

See Configure AMPS to run JIRA Core with additional applications installed for more information.

A compatibility table that matches application versions to compatible product versions can be found on the Atlassian Marketplace (e.g. the Service Desk listing).

Find copying and pasting scripts between the IntelliJ IDEA and the ScriptRunner web interface tedious? Us too. But there is a better way. Two of them, actually.

What if the fresh environment provided by your script plugin doesn’t map well to your production environment? For instance, maybe your script assumes the existence of a few custom fields, and reconfiguring those every time you restart Jira is tedious. Sure, you can avoid running the clean task for a while, but you’ll have to run clean if you want to test a new Jira version, which may be half of why you setup a development environment in the first place! And besides, it’s a pain to click through the same testing routine for all your scripts.

What if you could write a script that would automatically setup all the custom configuration that you needed (be they Jira issues & custom fields, Confluence spaces, Bitbucket repositories, or Bamboo plans) then verify that your script produced the expected results in that environment?

With automated testing in ScriptRunner, you can. In the project that you just setup, you can add tests under <module>/src/test/resources and run them via Admin → Built-in Scripts → Test Runner. See testing for more information.

One handy tool for debugging is adding an external tool in IntelliJ to run an arbitrary Groovy script against ScriptRunner.

If you don’t already have curl, you’ll need to download and install it.

Open IntelliJ’s preferences and navigate to Tools > External Tool. Click the plus button and create a new configuration called "Run in JIRA".

The key bits are:

You should have something similar to this:

When invoked, this will POST the body of the script file you’re working with to your locally running JIRA server and execute it, just as if you’d copy-and-pasted the code into the ScriptRunner console and hit 'Run'.

To invoke it, you can click Tools > External Tools > Run in JIRA. We recommend assigning it to a keyboard shortcut to make it easier to access.

We eat our own cooking around here, and we like to share our recipes. Check out the source code of the Template Comments for Jira Service Desk plugin (also available for installation on the Atlassian Marketplace).