How Everything s Connected

This page describes the connections between MPS, IntelliJ Community, JBR, TeamCity, and all open-source repositories.

JetBrains MPS is based on IntelliJ IDEA. It doesn't use all the plugins but extends it through the IntelliJ platform SDK to add support for tools that facilitate designing domain-specific languages. The projectional editor of MPS is a custom editor implementation instead of the standard text editor. Therefore, many text-based features of IntelliJ won't work (such as syntax language injections or code templates). Some features are unused or disabled such as the Program Structure Interface ⧉, which the platform typically uses as the layer responsible for parsing files and creating the syntactic and semantic code model.

MPS/IntelliJ IDEA requires a Java Runtime. Both use the JetBrains Runtime, a fork of OpenJDK. It includes several enhancements in font rendering, ligatures, HiDPI support, windowing/focus subsystems, performance improvements, and bug fixes. The repository mbeddr/build.publish.jdk publishes the needed runtimes for the different MPS versions on the itemis nexus server ⧉.

A zipped version of all MPS versions, as well as the most import components of MPS (jar files) such as the editor API or the model checker, are also published through the repository mbeddr/build.publish.mps to the itemis nexus server ⧉.

You can custom RCPs which are customized versions of MPS. The first big RCP was mbeddr. Its repository is mbeddr/mbeddr.core. The old homepage is mbeddr/ ⧉. The reusable plugins became part of the com.mbeddr.mpsutil subproject. is the old documentation. Some plugins and languages moved to a new repository JetBrains/MPS-extensions, especially the editor-related languages. JetBrains hosts this repository. Full Extension List | MPS Extensions contains a list of all extensions in this repository. Many extensions were contributed by itemis, a few of them by DSLFoundry. The documentation for both platforms is hosted on GitHub and the current website ⧉, respectively. Mbeddr.core has a dependency on MPS Extensions ⧉.

The mbeddr organization also hosts mbeddr.formal: FASTEN (FormAl SpecificaTion ENvironment), which is a set of DSLs to experiment with rigorous systems and safety engineering, and mps-qa, which is a quality assurance tooling for MPS (blog post ⧉).

A different platform that builds on the other two is IETS3/iets3.opensource, which mainly consists of KernelF ⧉. This extensible and functional language can be used in MPS as the core language of DSls and generate Java code.

Use the MPS build language to build MPS projects. The language generates Ant scripts you can execute directly on the command line. Other projects use Maven to call them. The most popular build automation tool is Gradle. Mbeddr/mps-gradle-plugin is a Gradle plugin that helps build MPS-based projects with Gradle. All MPS platforms and many other MPS projects use this plugin. It also contains a task download-jbr that can use the JBR artifacts published by the build.publish.mps repository. Some plugins are now part of the repository mbeddr/mps-build-backends ⧉, a dependency of the mps-gradle-plugin. It allows executing the plugin through the command line instead of using them via Gradle.

The platforms use the Maven publish plugin to publish the generated artifacts. This Gradle plugin allows to publish build artifacts to Apache Maven repositories. The scripts publish the artifacts to, a Nexus repository, and the Apache Maven registry of the corresponding GitHub project (example ⧉).

Two CIs are available to run the build and execute the tests: Use GitHub Actions for small or big repositories. They can be configured through the Actions tab in the corresponding repository (example ⧉) and saved in the .github/workflows directory.

Big repositories use the TeamCity server located at TeamCity is a build management and continuous integration server. When you push a new branch to any of the mentioned repositories, TeamCity triggers a build and executes the tests. Some projects require a code review and a successful build before you can merge a branch. Build configurations for the different projects are saved on the server. A build agent executes the actual build. The TeamCity server and the agents (sometimes not located on the same server) run inside Docker containers. The agent docker image's source is at mbeddr/ ⧉.