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).
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.
Automated publishing using private tokens, bundle signing, and secured connections are just a few types of security we provide to the users.
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.
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 signPlugin
task 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.
Find the org.jetbrains.intellij
plugin entry and upgrade it to the 1.x
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.
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()
.
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.
Properties of runIde
, runIdeForUiTests
, and buildSearchableOptions
tasks were removed:
ideaDirectory
- use ideDir
insteadjbreVersion
- use jbrVersion
insteadProperties of IntelliJPluginExtension
were removed:
alternativeIdePath
- use localPath
insteadpluginsRepository
accepting String
– pass closure insteadProperties of PublishTask
were removed:
username
and password
– the publishing authorization is based on the host
and token
propertiesPublishTask
was renamed to PublishPluginTask
intellij.ideaDependency.classes
are now available via intellij.ideaDependency.get().classes
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
Follow us
Bug and issue tracker
JetBrains blog
Twitter
Slack