Release and CI process with MPS

Here some things concerning first two questions:  

MPS itself is partly written on DSLs that are created inside it. So yes, you can share git repository.

If language engineer created migration script (if necessary) for changes in DSL, than domain expert will get notification about it after repository update and can migrate his solutions with migration assistant. But it can lead to some merge conflicts, that can be avoided by following recommended procedures for such cases.

For MPS standalone distribution it is a little bit more trickier: languages can be separated to individual MPS plugins, so update of language and providing migrations for it will affect only this plugin. In this case build script for this language can pack this changes to new version of plugin and domain expert can update just this plugin of his MPS standalone distribution instead of all IDE.
Platform allow you to set different versions for standalone IDE and plugins and provide compatible versions of IDE in plugins.

Thanks Victor.

Very well explained..

There is also way to create your own plugin repository, so update of plugins will be automated:
https://www.jetbrains.com/help/idea/managing-enterprise-plugin-repositories.html
https://www.jetbrains.com/help/idea/adding-plugins-to-enterprise-repositories.html

In fact you need only to implement Plugins List and Plugin Update Download:
http://www.jetbrains.org/intellij/sdk/docs/plugin_repository/api/api_reference.html

Right. This looks like the best and easiest way of distributing language packages. Nice.

Kudos

Hi m sch95, Victor,

I can weigh in from what I've learned from the mbeddr guys. They are using a binary repository (called a Nexus) in which they store all artifacts that are built in MPS and dependencies for other artifacts.

As for your final question (gradle build integration): some documentation about this can be found on the mbeddr wiki: https://github.com/mbeddr/mbeddr.core/wiki/Building-mbeddr and https://github.com/mbeddr/mbeddr.core/wiki/Building-mbeddr-extensions.

I am (under advisement of the mbeddr team) currently in the process of writing and reviewing a little howto on writing your own gradle build configuration that build MPS artifacts (automatically resolving specified dependencies to third party artifacts like the mbeddr platform). If everything goes well, this howto will appear soon on the mbeddr wiki.

Victor: thanks for all the useful extra info! Do you or anyone else within the MPS team have an idea how your own dedicated plugin repository compares to a Nexus and when you should use the one or the other?

Hi Eugen,
To be clear, I don't know much about mbeddr grandle integration and Nexus repository, so I can't compare them properly.

But I think, that way of plugin repository mentioned above is more suitable for end user experience in final product than for developing in continuous integration. And for me relations between DSL engineer and domain expert (what was the original question) is more likely first one, even if updates are frequent enough.
Of course plugin repository (to some extend) can be used in CI and main argument for this - it is already integrated into the platform, main argument against - you have to maintain your server with repository.

I must mention, that MPS team do not use this plugin repository extension, this is Idea platform system, that was created for all Idea platform based IDEs, so enterprise customers can provide their own repositories (private for example) for their plugins.
We just use one git repository, that is enough for us, because most of our plugins are internal plugins of MPS and we just run migrations on all repository and developers can merge after (and migrate their usages in branches). All this migrations are also provided to end users on update between MPS versions.

In fact any MPS plugin is just extension over Idea platform plugin mechanisms, so if you wrote some plugin, then you've already used it, just without some additional information for maintain plugin/IDE versions.

If understand mbeddr gradle integration right, then it is some sort of wrap around build language with additional functionality to resolving third party artifacts and publish results of build script to Nexus repository. It is better to ask their reasons for creating such system, but I guess build language has some limitations, that not allow them to integrate and publish to remote repository so freely.

But it is MPS, so you can always extend build language (it is Ant scripts in the end) to add support for any artifact repository you want and use Ant integration with any other build system you wish to use and more familiar with =)

Well, thanks for the further answers. This guide here really helps us to evaluate our further development and I hope it helps others too.

Eugen, I think this a very good idea. I would be very grateful if you can share your blog post about the grade build scripts with the community.