Platform Build Scripts¶
This page describes the MPS Extensions ⧉, and IETS3 ⧉ build scripts. They might look different in the future, but this guide should still be helpful. The build scripts from mbeddr ⧉ work similarly, but there's more than just one, so let's focus on the other two platforms.
MPS-extensions/build.gradle¶ ⧉
Let's ignore Modelix-related stuff. The script uses the mps-gradle-plugin ⧉, which contains some valuable tasks for Gradle-based builds with MPS.
Line 2: The build script block lists the used dependency repositories: the new itemis nexus server (https://artifacts.itemis.cloud) and the old one (projects.itemis.de ⧉).
Line 8 ⧉: The dependency block contains the reference to the mps-gradle-plugin.
Line 15: Use the plugin gradle-github-plugin ⧉ for publishing artifacts to GitHub. It's important to import the classes from the mps-gradle-plugin: import de.itemis.mps.gradle.*.
Line 28: Use the Gradle Wrapper to specify the Gradle version that Gradle should download: it must be compatible with the used Java version (compatibility matrix ⧉)
Line 34 ⧉: The variable ciBuild can affect the build, for example, by using a different version identifier for the artifacts.
Line 47 ⧉: Set the path to the Java installation.
Line 71: A few different ways exist to specify properties for the build. This guide ⧉ explains them.
Line 77: This list contains the Nexus repositories that Gradle uses for fetching the dependencies. Line 138 ⧉ contains the actual declaration.
Line 83-109: The logic for deciding the version identifier. It uses hardcoded values, the branch name, ciBuild, and the class GitBasedVersioning to create a suitable identifier. A local build gets version 1.0-SNAPSHOT as described in the Maven guide. This StackOverflow question ⧉ contains more information.
Line 112-123: The plugins directory varies depending on the operating system (Plugins directory | MPS ⧉).
Line 125 ⧉: The following variables contain the Nexus repositories the script uses to publish the artifacts.
Line 130-136: A new configuration named mps is declared, used for declaring the dependency on MPS. The dependencies block declares the dependency. Gradle doesn't automatically resolve the dependency because a custom configuration is used. Line 150 ⧉ and the following lines create the resolution task. configurations.mps.resolve() downloads the zip file, zipTree unzips it into the MPS home directory.
Line 168-174 ⧉: This dependency is needed to support the Junit Ant task.
Line 183-199 ⧉: Some system variables are set by prepending -D before the key-value pairs. These variables are declared in the build solution in the build script of the MPS project. Use this way to overwrite them on the command line.
Line 204-219 ⧉: The all script is a special MPS build script that calls all other build scripts. This task has the type BuildLanguages as described in the Gradle plugin documentation and executes the XML file created by the MPS build language. The following lines also declare tasks for building the languages and running the tests. They call the corresponding build scripts from the build module of this project (de.itemis.mps.extensions.build).
Line 221 ⧉: This task installs the nativelibs.loader plugin, which you can use for loading native code (e.g., C code) that is needed for a Java library(e.g., C debugger). A special plugin is needed because special methods for loading native code in Java exist. Don't use ordinary MPS solutions for this task because they can be reloaded in MPS, which isn't possible with native libraries. This plugin is implemented as an IntelliJ plugin and is unaffected by the MPS reloading mechanism.
Line 250 ⧉: This block declares the Junit Ant dependency.
Line 260-270 ⧉: These two tasks create zip files from the artifacts.
Line 272 ⧉: The clean task removes the generated MPS files, cleans the temporary folder, and removes the artifact folder's content.
Line 279-317: This block uses the Maven publishing plugin to publish the generated artifacts to different repositories, such as Nexus and GitHub Maven repositories. When building the project with GitHub Actions ⧉, the credentials are storable on the build server (e.g., TeamCity) or in the GitHub project.
Line 319-339: This block defines one publication de.itemis.mps:extensions. It also publishes a Maven pom file ⧉ that lists all the dependencies of this artifact (in this case: only MPS).
Line 376 ⧉: This block declares the publication for GitHub. Warning: It's impossible to publish an artifact with the same name on GitHub. It doesn't get overwritten.
The rest of the build script uses modelix/mpsbuild, a replacement for the MPS build language. Visit Exploring modelix/mpsbuild - Specific Languages ⧉ for initial information on this project.
iets3.opensource/build.gradle¶ ⧉
The build script looks like the script from MPS Extensions ⧉, so let's focus only on the differences.
Line 68-112 ⧉: The project has a dependency on mbeddr which you can override with a local dependency by setting the project variable forceLocalDependencies.
Line 134-139: This block declares a few configurations. The dependencies of these configurations are resolved in different Gradle tasks, for example, in the task resolvePcollections on line 179 ⧉.
Line 259-264: Additional to exporting the languages and solutions, the project also creates a standalone IDE (RCP) ⧉
Line 332-406 ⧉: This time, multiple publications exist. Not only the languages and tests are published but also some runtime Java libraries that KernelF needs (e.g. org.iets3.core.expr.datetime.runtime for the datetime language).
Line 409-421 ⧉: This task reads project libraries from projectlibraries.properties and generates libraries.xml in the .mps directory. During startup, MPS loads libraries. A library is, for example, mbeddr. The setup tasks use the task which you should execute when cloning the project.
Mbeddr Build Scripts¶
The root directory contains the main build.gradle. A build subfolder exists. The most crucial build files are com.mbeddr/build.gradle, which build mbeddr, and com.mbeddr/platform/build.gradle ⧉, which builds the mbeddr platform ⧉.