Building IntelliJ plugins from the command line

03 Aug, 2015
Xebia Background Header Wave

For a few years already, IntelliJ IDEA has been my IDE of choice. Recently I dove into the world of plugin development for IntelliJ IDEA and was unhappily surprised. Plugin development all relies on IDE features. It looked hard to create a build script to do the actual plugin compilation and packaging from a build script. The JetBrains folks simply have not catered for that. Unless you’re using TeamCity as your CI tool, you’re out of luck.

For me it makes no sense writing code if:

  1. it can not be compiled and packaged from the command line
  2. the code can not be compiled and tested on a CI environment
  3. IDE configurations can not be generated from the build script

Google did not help out a lot. Tomasz Dziurko put me in the right direction.
In order to build and test a plugin, the following needs to be in place:

  1. First of all you’ll need IntelliJ IDEA. This is quite obvious. The Plugin DevKit plugins need to be installed. If you want to create a language plugin you might want to install Grammar-Kit too.
  2. An IDEA SDK needs to be registered. The SDK can point to your IntelliJ installation.

The plugin module files are only slightly different from your average project.
Update: I ran into some issues with forms and language code generation and added some updates at the end of this post.

Compiling and testing the plugin

Now for the build script. My build tool of choice is Gradle. My plugin code adheres to the default Gradle project structure.
First thing to do is to get a hold of the IntelliJ IDEA libraries in an automated way. Since the IDEA libraries are not available via Maven repos, an IntelliJ IDEA Community Edition download is probably the best option to get a hold of the libraries.
The plan is as follows: download the Linux version of IntelliJ IDEA, and extract it in a predefined location. From there, we can point to the libraries and subsequently compile and test the plugin. The libraries are Java, and as such platform independent. I picked the Linux version since it has a nice, simple file structure.
The following code snippet caters for this:
[sourcecode lang=”groovy”]
apply plugin: ‘java’
// Pick the Linux version, as it is a tar.gz we can simply extract
def IDEA_SDK_URL = ‘’
def IDEA_SDK_NAME = ‘IntelliJ IDEA Community Edition IC-139.1603.1’
configurations {
bundle // dependencies bundled with the plugin
dependencies {
ideaSdk fileTree(dir: ‘lib/sdk/’, include: [‘*/lib/*.jar’])
compile configurations.ideaSdk
compile configurations.bundle
testCompile ‘junit:junit:4.12’
testCompile ‘org.mockito:mockito-core:1.10.19’
// IntelliJ IDEA can still run on a Java 6 JRE, so we need to take that into account.
sourceCompatibility = 1.6
targetCompatibility = 1.6
task downloadIdeaSdk(type: Download) {
sourceUrl = IDEA_SDK_URL
target = file(‘lib/idea-sdk.tar.gz’)
task extractIdeaSdk(type: Copy, dependsOn: [downloadIdeaSdk]) {
def zipFile = file(‘lib/idea-sdk.tar.gz’)
def outputDir = file("lib/sdk")
from tarTree(resources.gzip(zipFile))
into outputDir
compileJava.dependsOn extractIdeaSdk
class Download extends DefaultTask {
String sourceUrl
File target
void download() {
if (!target.parentFile.exists()) {
ant.get(src: sourceUrl, dest: target, skipexisting: ‘true’)
If parallel test execution does not work for your plugin, you’d better turn it off as follows:
[sourcecode lang=”groovy”]
test {
// Avoid parallel execution, since the IntelliJ boilerplate is not up to that
maxParallelForks = 1

The plugin deliverable

Obviously, the whole build process should be automated. That includes the packaging of the plugin. A plugin is simply a zip file with all libraries together in a lib folder.
[sourcecode lang=”groovy”]
task dist(type: Zip, dependsOn: [jar, test]) {
from configurations.bundle
from jar.archivePath
rename { f -> "lib/${f}" }
build.dependsOn dist

Handling IntelliJ project files

We also need to generate IntelliJ IDEA project and module files so the plugin can live within the IDE. Telling the IDE it’s dealing with a plugin opens some nice features, mainly the ability to run the plugin from within the IDE. Anton Arhipov‘s blog post put me on the right track.
The Gradle idea plugin helps out in creating those files. This works out of the box for your average project, but for plugins IntelliJ expects some things differently. The project files should mention that we’re dealing with a plugin project and the module file should point to the plugin.xml file required for each plugin. Also, the SDK libraries are not to be included in the module file; so, I excluded those from the configuration.
The following code snippet caters for this:
[sourcecode lang=”groovy”]apply plugin: ‘idea’
idea {
project {
languageLevel = ‘1.6’
ipr {
withXml {
it.node.find { node ->
node.@name == ‘ProjectRootManager’
}.’@project-jdk-type’ = ‘IDEA JDK’
logger.warn "=" * 71
logger.warn " Configured IDEA JDK ‘${jdkName}’."
logger.warn " Make sure you have it configured IntelliJ before opening the project!"
logger.warn "=" * 71
module {
scopes.COMPILE.minus = [ configurations.ideaSdk ]
iml {
beforeMerged { module ->
withXml {
it.node.@type = ‘PLUGIN_MODULE’
// <component name="DevKit.ModuleBuildProperties" url="file://$MODULE_DIR$/src/main/resources/META-INF/plugin.xml" />
def cmp = it.node.appendNode(‘component’)
cmp.@name = ‘DevKit.ModuleBuildProperties’
cmp.@url = ‘file://$MODULE_DIR$/src/main/resources/META-INF/plugin.xml’

Put it to work!

Combining the aforementioned code snippets will result in a build script that can be run on any environment. Have a look at my idea-clock plugin for a working example.

Update 1: Forms

For an IntelliJ plugin to use forms it appeared some extra work has to be performed.
This difference is only obvious once you compare the plugin built by IntelliJ with the one built by Gradle:

  1. Include a bunch of helper classes
  2. Instrument the form classes

Including more files in the plugin was easy enough. Check out this commit to see what has to be added. Those classes are used as “helpers” for the form after instrumentation. For instrumentation an Ant task is available. This task can be loaded in Gradle and used as a last step of compilation.
Once I knew what to look for, this post helped me out: How to manage development life cycle of IntelliJ plugins with Maven, along with this build script.

Update 2: Language code generation

The Jetbrains folks promote using JFlex to build the lexer for your custom language. In order to use this from Gradle a custom version of JFlex needs to be used. This was used in an early version of the FitNesse plugin.

Update 3: Using a gradle plugin

Darren Reid pointed me to a Gradle plugin developed by Jetbrains that basically does the same as what I outlined above. I gave the plugin a swing and it works really well. The plugin is simple to configure:
[sourcecode lang=”groovy”]
plugins {
id "org.jetbrains.intellij" version "0.0.26"
apply plugin: ‘org.jetbrains.intellij’
intellij {
version ‘14.1.4’
pluginName ‘idea-clock’
publish {
username jetbrainsUsername ?: ""
password jetbrainsPassword ?: ""
pluginId ‘7754’
Your jetbrainsUsername and jetbrainsPassword can be configured in $HOME/.gradle/
The differences with my approach is:

  • The project is loaded as a normal IntelliJ Java project. It’s not a “special” plugin project. This means the plugin can not be executed via the Run Configuration menu. Instead, it can be started via a gradle command (runIdea).
  • I was not able to run IntelliJ in debug mode.

Get in touch with us to learn more about the subject and related solutions

Explore related posts