The core tool for IntelliJ Platform plugin development is now 1.x! 🎉
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.
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.
The plugin adds dependencies to your preferred IntelliJ-based IDEs, built-in or third-party plugins, and JetBrains Runtimes (JBR).
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.
Automated publishing using private tokens, bundle signing, and secured connections are just a few types of security we provide to the users.
Extension and task properties now fully support the Lazy Configuration, which allows delaying value calculation until it's actually needed.
Gradle provides the Task Configuration Avoidance API to avoid configuring tasks if not needed during the ongoing process – thereby speeding up configuring tasks.
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.
Migration from Groovy to Kotlin language strengthened the development experience crucial for long-time support and introduced strong typing for Gradle configurations.
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.
We've introduced GitHub Actions, Dependabot, and Qodana integrations to provide rapid feedback for contributors and introduce better overall project quality.
Upgrading to 1.x requires some adjustments in the current Gradle configuration
The following example of upgrading the Gradle IntelliJ Plugin to version 1.x presents a project configuration based on the IntelliJ Platform Plugin Template using Kotlin DSL.
org.jetbrains.intellij plugin entry and upgrade it to the
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.
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:
To access a lazy property call
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.x 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.
Accessing properties requires direct
.get() call, like in Kotlin DSL.
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.
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.
buildSearchableOptions tasks were removed:
IntelliJPluginExtension were removed:
String– pass closure instead
PublishTask were removed:
password– the publishing authorization is based on the
PublishTaskwas renamed to
intellij.ideaDependency.classesare now available via
All the properties using a short
*Repo form were renamed:
For a better consistency with Gradle, all long
*Directory became short: