Gradle IntelliJ Plugin

The core tool for IntelliJ Platform plugin development is now 1.0! 🎉

What is the Gradle IntelliJ Plugin?

The Gradle IntelliJ Plugin is an extension to the Gradle build system and the preferred solution for creating IntelliJ Platform plugins.

It controls the building, testing, verification, and publishing steps of the plugin development workflow.

Creating a new Gradle-based IntelliJ Platform plugin can be handled with the New Project wizard or the IntelliJ Platform Plugin Template, a pure and preconfigured boilerplate.

Key features

Gradle IntelliJ Plugin makes plugin development easier

The plugin provides a number of tasks to the Gradle build system that helps create and maintain plugins for IntelliJ-based IDEs. Integration with tools and services for testing, verifying, and publishing plugins makes the overall development experience even better.

Dependency management

The plugin adds dependencies to your preferred IntelliJ-based IDEs, built-in or third-party plugins, and JetBrains Runtimes (JBR).


The IntelliJ Plugin Verifier integration allows you to check the binary compatibility of the plugin you’ve built against the specified IntelliJ-based IDE builds.


Running and debugging a plugin in multiple IDEs gives you the opportunity to check the desired case on your local environment using available IDEs.


The plugin signing task utilizes the Marketplace Zip Signer, increasing the security of the plugin publishing to JetBrains Marketplace.

Secured publishing

Automated publishing using private tokens, bundle signing, and secured connections are just a few types of security we provide to the users.

Easy to learn

The Gradle build system allows you to start with plugin development quickly. Relying on the already configured IntelliJ Platform Plugin Template is also a good pick.

What's new in 1.0?

Lazy Configuration

Extension and task properties now fully support the Lazy Configuration, which allows delaying value calculation until it's actually needed.

Task Configuration Avoidance

Gradle provides the Task Configuration Avoidance API to avoid configuring tasks if not needed during the ongoing process – thereby speeding up configuring tasks.

Plugin Signing

As a part of the Plugin Signing in Marketplace, the signPlugintask is now available as a part of the plugin to make the signing process as transparent as possible.

Rewritten in Kotlin

Migration from Groovy to Kotlin language strengthened the development experience crucial for long-time support and introduced strong typing for Gradle configurations.

Stepping away from Bintray and JCenter

In response to the sunsetting of Bintray and JCenter, all of the libraries maintained by JetBrains that the plugin relied on were published to Maven Central.

Better CI

We've introduced GitHub Actions, Dependabot, and Qodana integrations to provide rapid feedback for contributors and introduce better overall project quality.

How to upgrade?

Upgrading to 1.0 requires some adjustments in the current Gradle configuration

The following example of upgrading the Gradle IntelliJ Plugin to version 1.0 presents a project configuration based on the IntelliJ Platform Plugin Template using Kotlin DSL.

Find the org.jetbrains.intellij plugin entry and upgrade it to the 1.0 version.

Because of the lazy properties introduction, it is now required in Kotlin DSL to run explicitly the .set(value) setter method on the property passing the value of the expected type.

To specify dependencies to other plugins, it is now required to provide a list using intellij.plugins.set() method instead of intellij.setPlugins() accepting vararg input.

Using the Gradle Changelog Plugin requires delaying of the changelog.getLatest() method invocation to make its output available for the patchPluginXml.changeNotes property. Now it is available to use the built-in Provider from the Gradle API.

Breaking changes

Lazy Properties

Each property of the Extension or Task became a lazy property, which allows delaying the calculation of its value, i.e. after the configuration step.

In Kotlin DSL, it is now required to use the property setter explicitly, like: intellij.version.set("value").

To access a lazy property call .get(), like: intellij.version.get().

Restrictive Groovy syntax

Some of the properties in Gradle configuration written in Groovy language had extra setters available for handling input in various ways.

Because not every property had the same options provided, it was leading to confusion. Since the 1.0 version, the Groovy-based configuration also relies on lazy properties, but in opposite to Kotlin DSL, regular assign is available. Any other variations are now forbidden.

No signature of method exception

If some of the properties were previously set without the = assignment, Gradle would throw an exception that doesn't clearly point out the actual issue:

No signature of method: build_d7zsoyxgbh9rcsw4i4jurq1m0.intellij() is applicable for argument types: (...).

To address that issue, check for all the value assignments in your configuration and switch to the explicit assignment syntax.

Strict typing

Extension and Tasks input allowed for setting any value, thanks to the Object type, which was later stringified – or if it was an instance of Groovy Closure, called at first.

With the latest update, each property accepts a strictly defined input type or Provider returning this type.

Removed deprecated properties

Properties of runIde, runIdeForUiTests, and buildSearchableOptions tasks were removed:

  • ideaDirectory - use ideDir instead
  • jbreVersion - use jbrVersion instead

Properties of IntelliJPluginExtension were removed:

  • alternativeIdePath - use ideDir option in runIde and buildSearchableOptions tasks instead
    • pluginsRepository accepting String – pass closure instead

Properties of PublishTask were removed:

  • username and password – the publishing authorization is based on the host and token properties

Other changes

  • PublishTask was renamed to PublishPluginTask
  • intellij.ideaDependency.classes are now available via intellij.getIdeaDependency(project).classes

Naming cleanup

All the properties using a short *Repo form were renamed:

  • intellij.intellijRepo to intellij.intellijRepository
  • intellij.jreRepo to intellij.jreRepository
  • intellij.pluginsRepo to intellij.pluginsRepositories

For a better consistency with Gradle, all long *Directory became short:

  • intellij.sandboxDirectory to intellij.sandboxDir
  • prepareSandbox.configDirectory to prepareSandbox.configDir
  • runIde.ideDirectory to runIde.ideDir
  • runIde.pluginsDirectory to runIde.pluginsDir
  • runPluginVerifier.verificationReportsDirectory to runPluginVerifier.verificationReportsDir
  • runPluginVerifier.downloadDirectory to runPluginVerifier.downloadDir
  • verifyPlugin.pluginDirectory to verifyPlugin.pluginDir