modelix/mpsbuild by Sascha Lißon is a Gradle plugin together with an underlying library that can generate Ant scripts to build MPS projects, but using a Gradle DSL rather than MPS build projects as input.

The plugin is a fairly recent development but it is already used to build MPS-extensions. Here is an excerpt from the MPS-extensions Gradle build script:

mpsBuild {
    dependsOn(":model-api:assemble", ":model-api:copyJarsToMps")



    publication("grammarcells") {

    publication("cellfactory") {

As you can see, the DSL is quite concise. One important detail: although grammarcells depends on cellfactory, you don’t need to specify that explicitly, which also eliminates the need to update such dependencies if they change. No more “Dependencies should be extracted into the build script” error, and no mindless “Reload modules from disk” required.

The plugin will create a Gradle Maven publication from each publication(...) clause and will set up the publications so that they produce proper POM files with correct Maven coordinates and dependencies, and a simple ./gradlew publish will publish all the defined packages.

What is the use case for mpsbuild? I see it as a very promising experiment, even if quite limited at the moment. Its sweet spot lies with large MPS projects that are basically collections of useful languages or libraries. The only projects I am aware of that fit this description are the MPS utility libraries built by itemis: MPS-extensions, mbeddr, iets3.opensource, and the like.

In contrast, internal MPS-based projects usually want to produce an RCP, and in this context the absence of the build scripts changes from a blessing into a curse. To build an RCP you need a build script, and a build script will need build scripts for all its dependencies, transitively. This is also why MPS-extensions still provides a traditional MPS build script and an all-in-one artifact together with the fine-grained artifacts built via mpsbuild.

Currently, mpsbuild is best suited to building multiple small interdependent packages out of one large MPS project. If you only want to build one package for your entire project then specifying all the individual modules is redundant. This is not a fundamental limitation as it should be easy to implement inclusion and exclusion of modules based on a pattern. This way one could easily define a diagram publication containing all modules whose name begins with de.itemis.mps.editor.diagram, while excluding any sandboxes and tests.

Overall, the plugin is probably not going to be useful to you just now, unless you maintain one of the big library projects at itemis. But the idea of side-stepping the whole arcane world of MPS build scripts is definitely promising and worthy of pursuing further. I will be watching mpsbuild with great interest.