IntelliJ Platform Gradle Plugin 2.12.0 and the future of Gradle Grammar Kit Plugin

IntelliJ Platform Gradle Build Scripts
1

Hi, folks!

Yesterday, I released a new IntelliJ Platform Gradle Plugin 2.12.0 release with a pretty long changelog. The most important items are:

Add org.jetbrains.intellij.platform.grammarkit plugin with generateLexer/generateParser tasks.

When building a plugin that supports custom language plugins, you most likely rely on the Gramar Kit library for generating parser and lexer files. To make this process easier, we introduced the Gradle Grammar Kit Plugin.
Recently, when fixing the support for IntelliJ Platform 2026.1, I realized we need features and libraries present in the IntelliJ Platform Gradle Plugin. After copying some of the code between projects, I decided to merge those two into a single code base, which resulted in the Grammar Kit support being a part of the IntelliJ Platform Gradle Plugin.

From now on, you can apply in your gradle.build.kts:

plugins {
  id("org.jetbrains.intellij.platform") version "2.12.0"
  id("org.jetbrains.intellij.platform.grammarkit") version "2.12.0"
}

This will make the original generateLexer and generateParser tasks available for you, so you can (and should) drop the org.jetbrains.grammarkit plugin from your setup.

If your setup was using only the Grammar Kit features, the org.jetbrains.intellij.platform.grammarkit plugin can still be applied all alone.

The original Gradle Grammar Kit Plugin will be sunset in the near future.

Move sandbox directory from build/idea-sandbox to .intellijPlatform/sandbox; it’s path is accessible for reading and adjusting with intellijPlatform.sandboxContainer

Since this release, the sandbox directory is moved by default to a new location. This is the directory where all IDE settings and logs were stored when testing or running a fuest instance of the IDE with the runIde task.
Before, we used the build/idea-sandbox/ for it, which was removed when rebuilding the project, preventing you from persisting the setup between builds. That was an issue i.e. when you entered any license key in the IDE. It was already possible to change it in the Gradle setup, but it wasn’t obvious enough, so we decided to swith to .intellijPlatform/sandbox/ where settings will persist.

In order to revert this location back to the old place, use:

intellijPlatform {
    sandboxContainer = layout.buildDirectory.dir("idea-sandbox") 
}

You can also access the current location with intellijPlatform.sandboxContainer property for any custom scripting purposes you have.

Android Studio dependency resolution: improve version handling, prioritize local dependencies, and enhance test coverage

Google, starting from 2025.3.1.6/Panda RC1, changed the naming convention of Android Studio artifacts from https://edgedl.me.gvt1.com/android/studio/install/2025.2.3.9/android-studio-2025.2.3.9-mac_arm.dmg to https://edgedl.me.gvt1.com/android/studio/install/2025.3.1.6/android-studio-panda1-rc1-mac_arm.dmg, which prevented Gradle from resolving them.

Update minimal supported Gradle version to 9.0.0

The IntelliJ Platform Gradle Plugin started using the latest Gradle 9.4.0 for building. Unfortunately, it deprecated Kotlin 1.8, which was available in Gradle 8.* — this forces us to stick to what is described in their Compatibility matrix and compile plugin to Kotlin 2.2, meaning the lowest supported Gradle version is now 9.0.0.

The full changelog is avaialable here. If you have any questions related to the above highligh or any other changes, feel free to ask!

2

intellijPlatform.sandboxContainer returns something like C:\Projects\ij-extra-tools-pack\.intellijPlatform\sandbox.
Is it possible to have directly the path of the sandboxed IDE? (something like C:\Projects\ij-extra-tools-pack\.intellijPlatform\sandbox\IC-2025.1.4.1). I have to guess how the intellijPlatform plugin computes the “IC-2025.1.4.1” string. For now, I pick the platform type and version from my gradle.properties.

3

One more thing, I was configuring the sandbox directory the old way, via things like sandboxDirectory, sandboxSuffix, etc. It’s now partially broken, so I decided to rely on the new default settings.

I’m running a sandboxed IDE with a custom task named “runIde2” (val runIde2 by intellijPlatformTesting.runIde.registering {....}) because I needed to set multiple jvmArgs, and some of them cannot be set with the regular runIde task.
Question: when running my task, I see a suffix is added to the config, log, plugins, and system directories. Is it possible to not apply a suffix?

image
image266Ă—297 2.82 KB

It tried to set

prepareSandboxTask {
    sandboxSuffix = ""
}

but it now says I should declare :prepareSandbox_runIde2 as an input of :buildPlugin. I don’t understand why.
More exactly, it says:

* Exception is:
org.gradle.internal.execution.WorkValidationException: Some problems were found with the configuration of task ':prepareSandbox_runIde2' (type 'PrepareSandboxTask').
  - Gradle detected a problem with the following location: 'C:\Projects\ij-extra-tools-pack\.intellijPlatform\sandbox\IC-2025.1.4.1\plugins'.
    
    Reason: Task ':buildPlugin' uses this output of task ':prepareSandbox_runIde2' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.

Possible solutions:
      1. Declare task ':prepareSandbox_runIde2' as an input of ':buildPlugin'.
      2. Declare an explicit dependency on ':prepareSandbox_runIde2' from ':buildPlugin' using Task#dependsOn.
      3. Declare an explicit dependency on ':prepareSandbox_runIde2' from ':buildPlugin' using Task#mustRunAfter.

But I see no reason to do that.
It worked correctly with the previous platform plugin.

Thanks

4

As the name says — it’s a container for all IDE-specific directories. At the top level, you cannot guess which IDE it is there. That depends on your tasks. If you work with runIde, it implements the SandboxAware, which has sendbox-relevant fields that point you to the directory related to the base IntelliJ Platform dependency.
Same, the TestIdeTask, it’ll point to the directory related to the base IntelliJ Platform dependency, but config, log, and similar directories have the _test suffix.
With this release, nothing changed regarding accessing and resolving sandbox locations.

This is expected that for runIde and runIde2, there are different suffixed directories created. That’s done like that to avoid conflicts when running different tasks.
You can alter that behavior by adjusting the sandboxSuffix property of the PrepareSandboxTask.
The default runIde is associated with prepareSandbox default task.
For your runIde2, you can access the related sandbox task with:

val runIde2 by intellijPlatformTesting.runIde.registering {
    // ...
    prepareSandboxTask {
        sandboxSuffix = ""
    }
}
5

Thx for the details.

val runIde2 by intellijPlatformTesting.runIde.registering {
    // ...
    prepareSandboxTask {
        sandboxSuffix = ""
    }
}

still generates the error I mention.

6

This is probably related to another issue that is caused by a new location of the sandbox. It’s weird that tests didn’t fail on that.
I’ll fix it soon.

7

Hum, I was running gradlew buildPlugin runIde2. It’s ok if I run gradlew runIde2 directly.
There was no problem with the previous platform plugin version.

Anyway, this is not a real issue.
I think everything is ok now. Thx a lot for your help!

Just one last thing, and I’m sorry to insist on this: is there any progress regarding the build times on Windows? It’s still terribly slow.

8

The runIde tasks don’t need the fully built plugin as they work on the sandbox, so you should skip the buildPlugin task for performance reasons.

Yes, we have picked this story back up and discussed it this week with @robert.novotny and Florian, who will now work on it. Related ticket: MP-7927

2 Likes
9

Do you know if anyone is also looking at issues with Windows/ARM64? I would love to revisit moving my plugin from old-school ant to latest-and-greatest Gradle, but of course not until these performance issues are addressed on Windows, and also some Windows/ARM64-specific issues that I hit.

UPDATE: It looks like perhaps many Gradle-specific Windows/ARM64 issues were addressed late last year:

I’m currently trying to see if switching IntelliJ IDEA’s Gradle plugin to use that instead of the bundled one helps at all. Fingers crossed!

UPDATE 2: The good news is that with Gradle 9.4.0, the build works on Windows/ARM64 without any workarounds. The bad news is that when I execute the runIde task, the IDE never comes up, at least not completely. I’ve seen it get to the splash screen, but that process seems to hang interminably. And many times it never even gets that far. I’m trying to see if perhaps there’s still some cruft from the earlier Gradle versions that might be getting in the way.