Improvements to Building IntelliJ Platform
We’ve recently made some changes to how we build IntelliJ Platform, specifically in how we handle external dependencies, such as the Kotlin compiler.
IntelliJ Platform is the core code of IntelliJ IDEA, and powers all of our IDEs – IDEA Ultimate, WebStorm, PyCharm, Rider, and so on. It’s also an open source project, making up most of the IntelliJ IDEA Community Edition repo, and can be used to build your own IDEs that make use of IntelliJ’s editors, user interface and infrastructure for projects, rich language parsing, refactoring, navigation, testing and much more, just like Android Studio and the Cursive Clojure IDE do.
Of course, building a product as complex as IntelliJ IDEA Community Edition requires a number of external dependencies, such as the Kotlin compiler and plugin and JetBrains’ own version of the JDK, which contains important fixes for IntelliJ Platform.
Until recently, these dependencies were resolved against our own internal TeamCity instance. However, this has a number of disadvantages, especially when building outside of the JetBrains network – it’s hard (sometimes impossible) to get the exact same dependencies locally, especially when the versioning of these dependencies is based on TeamCity tags.
To address these issues, we’ve added a new Gradle module to the community project used to build IntelliJ IDEA Community Edition, which will automatically set up these external dependencies as part of the existing build process.
This module will download and prepare the correct versions of the JetBrains JDK, JRE and the Kotlin compiler and plugin. (The setupJetSign.gradle and setupAndroidSdk.gradle files you can see in the screenshot above are helpers for official JetBrains releases and products, and don’t do anything unless you’re on the internal JetBrains network.)
Most importantly, the versions of the dependencies are fixed, and recorded in the repo, in the build/dependencies/gradle.properties file.
If you wish to build IntelliJ Platform, or IntelliJ IDEA Community Edition with different versions of these dependencies, then you should either modify this file, or use the appropriate org.gradle.project system property, such as -Dorg.gradle.project.jdkBuild=u112b809.1.
All of this happens automatically as part of the existing build process, so you shouldn’t need to trigger this manually. But if you do need to, simply invoke the setupDependencies Gradle task on the project.
Introducing this new Gradle module and storing the version information in the repo will make it easier to acquire and set up dependencies, and ensure we’re always using the correct versions.
Finally, this is the first time we’ve added a Gradle module to the IntelliJ IDEA project. During setup, we found and fixed some problems with Gradle support in IntelliJ IDEA itself, and so we highly recommend using at least IntelliJ IDEA 2017.1 (or the just released 2017.2!) for development of IntelliJ IDEA Community Edition or your own IntelliJ-Platform-based IDE.
Subscribe to Blog updates
Wayland Support for IntelliJ-based IDEs
For Linux users of IntelliJ-based IDEs, an exciting advancement is on the horizon – the upcoming support of the Wayland display server protocol. This update is set to bring a host of benefits, including solving the age-old fractional scaling problem and elevating desktop integration when working wit…
Language Server Protocol (LSP) for Plugin Developers
With the 2023.2 release cycle, IntelliJ-based IDEs now support the Language Server Protocol (LSP). Discover how this may improve the assistance for custom language-specific features and learn how to begin integrating LSP into a plugin for your IDE.
Busy Plugin Developers Newsletter – Summer 2022
Read this Newsletter to learn about the latest JetBrains Marketplace news and plugin development tooling updates.
IntelliJ Project Migrates to Java 17
The source code of the IntelliJ project was recently migrated to Java 17. We still have some modules compiled to be compatible with older Java versions so we can support running users’ projects under these versions. However, most of the platform and plugin modules now use Java 17, and the upcoming 2…