There is an existing Gradle-side solution that may be relevant to both consuming MPS and packaging downstream plugins with platform-specific files: the IntelliJ Platform Gradle Plugin.
Using MPS as the target platform
MPS is supported as a first-class IntelliJ Platform dependency. The plugin reads the JetBrains product-release metadata, resolves the official MPS distribution appropriate for the machine running Gradle, downloads it, and exposes the extracted installation to the build and test tasks.
The following configuration uses the current snapshot of the Gradle plugin:
// settings.gradle.kts
pluginManagement {
repositories {
// Required for the 2.19.0-SNAPSHOT plugin release
maven("https://central.sonatype.com/repository/maven-snapshots/")
gradlePluginPortal()
}
}
// build.gradle.kts
plugins {
id("org.jetbrains.intellij.platform") version "2.19.0-SNAPSHOT"
}
repositories {
mavenCentral()
intellijPlatform {
defaultRepositories()
}
}
dependencies {
intellijPlatform {
mps("2026.2-EAP1")
}
}
The configured MPS installation can then be used by the regular plugin tasks, for example:
./gradlew runIde
./gradlew test
./gradlew buildPlugin
This is useful for projects such as MPS-extensions or mbeddr when their builds run on platform-specific CI agents. Each agent can consume the MPS distribution published for its platform instead of downloading a multi-platform kit and manually constructing a local MPS installation just to compile or test a plugin.
Connection with native plugin variants
The upcoming 2.19.0 release also introduces the intellijPlatform.nativeVariants feature. It follows essentially the same model proposed in this discussion, but at the plugin distribution layer:
- the regular plugin JAR and other shared files form the common part;
- native files are configured separately for each OS and architecture;
- the plugin produces a distinct distribution for every target variant;
- every variant declares the corresponding IntelliJ Platform OS and architecture module dependencies, allowing the platform to select only compatible plugins.
For example:
intellijPlatform {
pluginConfiguration {
ideaVersion {
// Native compatibility modules are available since 2026.1.
sinceBuild = "261"
}
}
nativeVariants {
enabled = true
linux {
x86_64.from("native/linux-x86_64")
arm64.from("native/linux-arm64")
}
mac {
x86_64.from("native/mac-x86_64")
arm64.from("native/mac-arm64")
}
windows {
x86_64.from("native/windows-x86_64")
arm64.from("native/windows-arm64")
}
}
}
Running:
./gradlew buildPluginVariants
produces separate archives such as:
my-plugin-1.0.0-linux-x86_64.zip
my-plugin-1.0.0-linux-arm64.zip
my-plugin-1.0.0-mac-x86_64.zip
my-plugin-1.0.0-mac-arm64.zip
my-plugin-1.0.0-windows-x86_64.zip
my-plugin-1.0.0-windows-arm64.zip
The generated descriptors receive variant-specific versions and dependencies such as:
<version>1.0.0-linux-arm64</version>
<depends>com.intellij.modules.os.linux</depends>
<depends>com.intellij.modules.arch.arm64</depends>
When native variants are enabled, publishPlugin publishes these variant archives instead of the single platform-independent plugin archive.
This looks directly relevant to MPS-extensions, mbeddr, or any other MPS plugin that contains native executables or libraries. Such a project can keep its common plugin content shared and publish only the appropriate native payload with each OS/architecture variant.
Relationship to MPS-40103 and the proposed MPS kit
MPS-40103 addresses the same underlying problem one level lower, while assembling MPS itself. It records that OS-specific IntelliJ Platform plugins—initially JCEF—must be carried into the corresponding MPS distributions. The implemented MPS build layout puts platform overlays under __overlay__/<os>.<arch>/ inside the internal mps-platform.tar.gz artifact.
The IntelliJ Platform Gradle Plugin does not split or publish the MPS platform artifact itself. Therefore, it does not replace the generic-MPS-plus-platform-overlays proposal when a single downstream build must assemble complete MPS-based products for several target platforms.
The two mechanisms are nevertheless closely related:
- MPS generic distribution plus overlays would provide the common and native portions of the MPS platform.
- IntelliJ Platform Gradle Plugin native variants provide the common and native portions of plugins installed on that platform.
- The
mps(...) dependency helper lets a Gradle build consume an already assembled, published MPS distribution for its current build platform.
Together, these provide a consistent model from the platform distribution through to downstream plugins: keep common content shared and express OS/architecture-specific content explicitly.
Testing the snapshot
The native-variants implementation is available for testing in:
org.jetbrains.intellij.platform:org.jetbrains.intellij.platform.gradle.plugin:2.19.0-SNAPSHOT
from:
https://central.sonatype.com/repository/maven-snapshots/
One MPS-version detail is worth calling out: the currently published 2026.2-EAP1 download is build 262.9437.166, whereas MPS-40103 is marked fixed in MPS-262.9437.249. Consequently, mps("2026.2-EAP1") can be used to test the Gradle integration and native-plugin-variant workflow, but that public MPS download does not yet contain the MPS-40103 fix.
Testing the corrected MPS platform payload requires a published MPS build 262.9437.249 or newer. If such a build is available internally as an extracted MPS installation, it can be used immediately:
dependencies {
intellijPlatform {
local("/path/to/MPS-262.9437.249")
}
}
It would be valuable to try 2.19.0-SNAPSHOT in an existing MPS-extensions or mbeddr build. In particular, this could show which parts of their current platform-specific artifact handling are already covered by mps(...) and nativeVariants, and which parts still require the proposed changes to the way MPS itself is published.
