{"id":497624,"date":"2024-07-30T18:26:35","date_gmt":"2024-07-30T17:26:35","guid":{"rendered":"https:\/\/blog.jetbrains.com\/?post_type=platform&p=497624"},"modified":"2025-09-16T18:55:10","modified_gmt":"2025-09-16T17:55:10","slug":"intellij-platform-gradle-plugin-2-0","status":"publish","type":"platform","link":"https:\/\/blog.jetbrains.com\/pt-br\/platform\/2024\/07\/intellij-platform-gradle-plugin-2-0","title":{"rendered":"IntelliJ Platform Gradle Plugin 2.0 Is Out!"},"content":{"rendered":"\n

Version 2.0 of the IntelliJ Platform Gradle Plugin is now available! Previously called the Gradle IntelliJ Plugin, this updated plugin for the Gradle build system simplifies the configuration of environments for building, testing, verifying, and publishing plugins for IntelliJ-based IDEs. Redesigned and rewritten, it addresses community-reported issues and feature requests from previous versions.<\/p>\n\n\n\n

The path to 2.0<\/h1>\n\n\n\n

The project to create this plugin began in 2015 with the goal of simplifying the development and testing of plugins for JetBrains IDEs. Initially, it was developed in Groovy, which remained the primary language for the first six years, during the 0.x releases.<\/p>\n\n\n\n\n\n\n\n

In May 2021, version 1.0 was released, marking a complete migration to Kotlin. This transition addressed multiple issues thanks to Kotlin\u2019s strong typing and null safety, though the core architecture remained unchanged. Around the same time, Gradle announced the configuration and build cache mechanisms. Those improvements in the Gradle build system highlighted fundamental weaknesses in the Gradle IntelliJ Plugin, revealing that maintaining it without workarounds was no longer viable.<\/p>\n\n\n\n

In the summer of 2023, we started adjusting the core functionality \u2013 the beginning of a challenging, year-long journey towards the release of version 2.0.<\/p>\n\n\n\n

<\/p>\n\n\n\n

New strategy for repository and dependency management<\/h1>\n\n\n\n

One of our main goals was fixing an architectural problem in the 1.x versions, which applied repositories and dependencies implicitly during task runtime. This approach had numerous side effects, addressed in the new 2.0 release.<\/p>\n\n\n\n

Repositories defined explicitly<\/h2>\n\n\n\n

The old version tried to keep configuration simple by adding all necessary repositories when the IntelliJ Platform dependency was resolved. The fixed repository list made Gradle search for dependencies in locations irrelevant to project needs or even unavailable for resolving.<\/p>\n\n\n\n

repositories {\n    mavenCentral()\n\n    intellijPlatform {\n        \/\/ use the recommended repository list\n        defaultRepositories()\n\n        \/\/ or explicit set\n        jetbrainsIdeInstallers()\n        releases()\n        localPlatformArtifacts()\n        intellijDependencies()\n        \/\/ ...\n    }\n\n    maven("...") {\n       authentication {\n           \/\/ ...\n       }\n    }\n}<\/pre>\n\n\n\n
The current solution allows using a recommended set of repositories or using only specific elements whenever you don\u2019t need others or decide to replace them with a custom artifactory.<\/p>\n\n\n\n
All resources as dependencies<\/h2>\n\n\n\n
The solution present in 1.x requested dependencies and tools in the task execution phase \u2013 this prevented Gradle from caching the project configuration or task output. This could also result in unsatisfied requests when working in environments with limited network capacity.<\/p>\n\n\n\n
With the 2.x release, everything required for building, testing, and verifying the plugin is defined as a dependency.<\/p>\n\n\n\n
The new approach requires explicit declarations of the IntelliJ Platform and all other dependencies:<\/p>\n\n\n\n
dependencies {\n   testImplementation(libs.junit)\n\n   intellijPlatform {\n       intellijIdeaCommunity("2023.2.7")\n       instrumentationTools()\n       pluginVerifier()\n       testFramework(TestFrameworkType.Platform)\n   }\n}<\/pre>\n\n\n\n
Relying fully on the Gradle approach for managing dependencies makes it possible to involve caching for every requested resource and avoid resolving dependencies eagerly.<\/p>\n\n\n\n
Advanced dependency management<\/h2>\n\n\n\n
Changes applied to repository and dependency configuration allow involving advanced Gradle techniques, like declaring centralized repositories. All of the project repositories can now be specified within the settings.gradle.kts<\/code> file, which applies them to all declared project modules.<\/p>\n\n\n\n
import org.jetbrains.intellij.platform.gradle.extensions.intellijPlatform\n      \nplugins {\n   id("org.jetbrains.intellij.platform.settings") version "2.0.0"\n}\n\n\ndependencyResolutionManagement {\n   repositoriesMode = RepositoriesMode.FAIL_ON_PROJECT_REPOS\n\n   repositories {\n       mavenCentral()\n\n       intellijPlatform {\n           defaultRepositories()\n       }\n   }\n}<\/pre>\n\n\n\n
From now on, the repositories {}<\/code> block in any build.gradle.kts<\/code>  is redundant.<\/p>\n\n\n\n
Powerful DSL<\/h1>\n\n\n\n
The new intellijPlatform {}<\/code> extension replaces the old intellij {}<\/code> and facilitates the detailed configuration of all relevant plugin configuration values, as well as signing, verifying, and publishing plugins:<\/p>\n\n\n\n
intellijPlatform {\n   pluginConfiguration {\n       version = providers.gradleProperty("pluginVersion")\n       name = "My Awesome Plugin"\n\n       description = ...\n       changeNotes = ...\n\n       ideaVersion {\n           sinceBuild = "223"\n           untilBuild = "242.*"\n       }\n   }\n\n   signing {\n       \/\/ ...\n   }\n\n   publishing {\n       \/\/ ...\n   }\n\n   pluginVerification {\n       \/\/ ...\n   }\n}<\/pre>\n\n\n\n
All extension properties and helper methods accept values passed either eagerly or lazily wrapped with Provider, which is available in the Gradle API. However, the simple property assignment in the Kotlin DSL, introduced in Gradle 8.2, keeps this change transparent.<\/p>\n\n\n\n
In addition to the root intellijPlatform {}<\/code> extension, new extensions have been introduced for the repositories {}<\/code> and dependencies {}<\/code> blocks. Each of these extensions provides dedicated helpers for applying repositories and dependencies related to the development of plugins for the IntelliJ Platform. This approach offers full control over what is applied to the configuration.<\/p>\n\n\n\n
Improved testing experience<\/h1>\n\n\n\n
The changes in how the IntelliJ Platform and dependencies in bundled and external plugins are applied to the project have opened up new possibilities in testing. You can now create custom run and test tasks targeting different IntelliJ Platform types and versions or plugin sets without changing the IntelliJ Platform version and type used to build the plugin.<\/p>\n\n\n\n
Using the new intellijPlatformTesting {}<\/code> extension, you can register tasks of various types and purposes:<\/p>\n\n\n\n
val runPhpStorm by intellijPlatformTesting.runIde.registering {\n   type = IntelliJPlatformType.PhpStorm\n   version = "2024.2"\n\n   plugins {\n       plugin("pluginId", "1.0.0")\n       disablePlugin("bundledPluginId")\n   }\n}<\/pre>\n\n\n\n
The code above creates a new runPhpStorm<\/code> task for running PhpStorm 2024.2 locally for manual testing purposes with the pluginId<\/code> installed from JetBrains Marketplace<\/a> and the bundledPluginId<\/code> plugin disabled.<\/p>\n\n\n\n
This approach helps with running manual or automated tests for different scenarios, such as ones where bundled plugins are disabled or optional plugins are installed.<\/p>\n\n\n\n
Multi-project builds support<\/h1>\n\n\n\n
To address previous issues with multi-project builds, the IntelliJ Platform Gradle Plugin has been restructured into several sub-plugins. These sub-plugins can be applied selectively based on the architecture of your project.<\/p>\n\n\n\n
This modular approach allows for the application of specific features, such as providing IntelliJ Platform dependencies to a project submodule, without introducing unnecessary tasks.<\/p>\n\n\n\n
\"\"<\/p>\n\n\n\n
For projects using IntelliJ-based IDEs, the main module should always include the org.jetbrains.intellij.platform<\/code> plugin in its configuration file. In contrast, other submodules should utilize the org.jetbrains.intellij.platform.module<\/code> plugin. This ensures the proper export of output archives and optimizes the build process. For submodules that require only access to the IntelliJ Platform dependency, the org.jetbrains.intellij.platform.base<\/code> plugin should be applied.<\/p>\n\n\n
\n
\"\"<\/figure><\/div>\n\n\n
New name and requirements<\/h1>\n\n\n\n
This release brings major configuration and conceptual changes. In order to help distinguish the new configuration from the old one, version 2.0 of the plugin has a new ID: org.jetbrains.intellij.platform<\/code>.<\/p>\n\n\n\n
Another reason for the name change was confusion of the Gradle IntelliJ Plugin with the Gradle plugin, which is bundled in IntelliJ IDEA and offers actual Gradle integration features. The name “IntelliJ Platform Gradle Plugin” highlights that it is the “IntelliJ Platform Plugin” for the “Gradle” build system.<\/p>\n\n\n\n
To make it possible to introduce solutions that address almost all of the issues reported over the last few years, it was necessary to limit support for older versions of the IntelliJ Platform, Gradle, and Java Runtime. IntelliJ Platform Gradle Plugin 2.0 requires the following minimal versions<\/strong>:<\/p>\n\n\n\n