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.