Migration Guide

When opening a project in a newer version of MPS, all the automated migration scripts that come with that version of MPS will be executed to bring the project up to date with the languages and APIs. Sometimes additional manual steps might be needed or some special care must be taken by the user. This page lists such instructions for each past version of MPS.

Migration to MPS 2021.2

NodeTextCases need regeneration

When upgrading to 2021.2.6 all NodeTestCases have to be regenerated for them to run successfully. Otherwise you will be getting exceptions like

                    java.lang.reflect.InvocationTargetException
                    at jdk.internal.reflect.GeneratedMethodAccessor26.invoke(Unknown Source)
                    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
                    at java.base/java.lang.reflect.Method.invoke(Method.java:566)
                    at com.intellij.execution.process.ProcessHandler$2.invoke(ProcessHandler.java:247)
                    at com.sun.proxy.$Proxy32.onTextAvailable(Unknown Source)
                    at com.intellij.execution.process.ProcessHandler.notifyTextAvailable(ProcessHandler.java:221)
                    at jetbrains.mps.execution.configurations.implementation.plugin.plugin.FakeProcessHandler$BlockingReader.onTextAvailable(FakeProcessHandler.java:155)
                    at com.intellij.util.io.BaseOutputReader.sendText(BaseOutputReader.java:205)
                

Replace implicit node.toString() with explicit smodel operation

A new node.presentation operation and a migration have been introduced to jetbrains.mps.lang.smodel. The migration replaces the usages of a node in string concatenation ("string" + node and node + "string") with the explicit node.presentation operation. At the moment, this operation delegates to the getPresentation() behavior method, which is what node.toString() used to do. Since MPS ceased to use the getPresentation() behavior method in the toString() method implementation, it is advised to use explicit node operations (like node.presentation, node.getPresentation() or any other tailored behavior) when you intend to show the node presentation to the end-user.

Split MPS.Core stub models into distinct modules

The stub models exposed through the MPS.Core module (lib/mps-core.jar, lib/mps-generator.jar and lib/mps-textgen.jar) have been separated into MPS.Generator and MPS.Textgen. This mostly impacts users who use the generator or the textgen APIs directly.

An automated migration merely updates references to use affected stubs to be used from the new modules. If it fails, the MPS.Generator and MPS.TextGen can be imported manually and then the classes from the proper modules must be selected in code using the code completion dialog.

For compatibility, MPS.Core still exposes the jars, but it will cease to expose them in 2021.3.

Plugin descriptor placement

The IntelliJ platform now loads plugins only if their plugin descriptor (the plugin.xml file) is located in a specific place in the plugin layout: plugin_folder/lib/one_of_the_plugins.jar!/META-INF/plugin.xml Previously, the META-INF/plugin.xml was allowed to be placed anywhere in the plugin folder.

Unless the plugin descriptor is mentioned explicitly in the plugin layout at the right location, an automatic transaction will generate it when the build script is generated. It will add the required jar file to the plugin layout and will make it hold hold the plugin descriptor. The code intended for adding during generation is displayed in a read-only section of the plugin layout:

An intention called "Override Plugin Descriptor Layout" is available that allows the build script author to override the default behavior with her own - the intention generates the required part of the layout and enables it for manual editing:

An inspection will report a warning whenever the plugin descriptor cannot be found in the layout definition.

Last modified: 08 September 2022