What's new in MPS 2.5



IntelliJ IDEA integration

MPS 2.5 can be run as a plugin for IntelliJ IDEA enabling MPS-based DSLs to be used directly in a Java IDE, interoperating tightly with other elements of the project. Although you need MPS in its entirety to create languages, IntelliJ IDEA represents a convenient additional channel for DSL distribution.


Editor

Enabling MPS inside a Java module is as simple as adding the MPS facet to it. Just like in MPS you can create models, import any MPS languages and start instantiating the root nodes. The root nodes are displayed in the Project View together with the other project sources and files. The projectional editor for the root nodes opens directly in IntelliJ IDEA so all your code stays within a single IDE.


Version Control

When comparing versions or resolving conflicts in MPS models, you can rely on the MPS structural diff/merge tool, just like in MPS. The tool will render the model content in a domain specific rather then the persistence-specific way:


Code Generation

The code generation process of MPS models is tied to the IntelliJ IDEA's make/rebuild project actions and so will be triggerred automatically. You hit Compile in IDEA and your MPS code gets generated and compiled as well. No need for extra steps.

The generation-time errors are propagated into the Messages View alongside all other compilation problems. You also have the possibility to navigate to the corresponding model elements by clicking on the displayed error:


Debugger Integration

The MPS debugger has been integrated into IntelliJ IDEA as well. When debugging your Java code you can set breakpoints directly inside the DSL code and so the IntelliJ IDEA debugger will be stopped at the appropriate place allowing you to explore the stack trace and the variables.

Distribution

The MPS plugin distribution contains 4 separate plugins at the moment. Some of the MPS functionality can be easily switched off by disabling the corresponding plugins in the Plugins configuration dialog. At the same time, user-specific DSLs can also be packaged as separate plugins and potentially distributed together with the MPS plugins to deliver your own powerful DSL features to the IntelliJ IDEA developers.



New Build Language

Build Language is an extensible build automation DSL for defining builds in a declarative way. Generated into Ant, it leverages Ant execution power while keeping your sources clean and free from clutter. Organized as a stack of MPS languages with ANT at the bottom, it allows each part of your build procedure to be expressed at a different abstraction level. Building a complex artifact (like an MPS plug-in) could be specified in just one line of code, if you follow the language conventions, but, at the same time, nothing prevents you from diving deeper and customize the details like file management or manifest properties.


Modular builds

Build script dependencies allow you to organize your build as a sequence of steps, each of which may potentially run on a different machine. At generation time, a sophisticated resolution mechanism transforms the high-level dependencies into the appropriate ANT tasks. For example, a dependency on a java module is replaced with its compiled jar location. Referring to and depending on the elements packaged inside existing archives will implicitly extracts them without any extra effort on your side.


Plug-ins packaging

Distributing languages as plug-ins for either IntelliJ IDEA, MPS or as your own standalone IDE has become an extremely easy task. The functionality has been packaged into an extension to Build Language, which knows how to build MPS modules and supports all kinds of packaging. You can either write the whole script by hand or rely on the Build Solution Wizard, which helps you start with a new script.


You can refer to the User Guide and to the Build Language documentation for more details.



Out-of-the-box languages

Customizable scopes

An element that contains a reference to some other element typically knows nothing about the scope applicable to the reference. In such cases the best solution for finding applicable elements is to forward the request upwards in the AST. By implementing the ScopeProvider interface you can intercept such requests coming from your descendants and have full control over their scopes. Since BaseLanguage itself now also follows this strategy, you can easily restrict visible elements in embedded statements or expressions.


Custom persistence for MPS models through stubs

With the improved jetbrains.mps.lang.stubs language, which now supports write as well as read operations, it is now possible to declare a custom stubs model manager that supports model saving functionality. Using this extension point you can teach MPS how to interoperate with any custom persistence syntax. You can load and save your models from and into a format that fits your needs best. Read more at the Custom Persistence page.


New XML language

A new language named jetbrains.mps.core.xml was introduced in MPS 2.5. This XML language has been designed in accordance to the XML specification.


Textual references

The reference representation can now vary depending on the reference location, as it is in many existing textual languages. It allows languages to support the notion of qualified reference when simple name of the target element is not enough. The new API requires developers to provide the referenceText value as a part of the Scope implementation (see jetbrains.mps.scope.Scope). All references in BaseLanguage now support java-style resolving. Also, in case of broken references the referenceText serves as a hint to the developer to fix it easily.


Suppressing errors

One of very effective ways to maintain high quality of code in MPS is the instant on-the-fly code analysis that highlights errors, warnings or potential problems directly in code. Just like with other code quality reporting tools, it is essential for the user to be able to mark false positives so that they are not reported repeatedly. MPS now provides the language developers with a customizable way to suppress errors in their languages. This functionality was used to implement Suppress Errors intention for BaseLanguage:


One place where this feature is also useful are the generators, since type errors, for example, are sometimes unavoidable in the templates.

Changes in the Refactoring language

In order to make the structure of MPS core languages more consistent and clear, the Refactoring language has been changed considerably. Several new and easy-to-use constructs have been added and parts of the functionality was deprecated and moved into the Actions language.



IDE enhancements

Dependencies analyzer

The Dependencies Analyzer can analyze and report dependencies among modules or models. It detects and highlights the elements that your code really refers to.


Module Dependencies Tool

The Module Dependencies Tool allows the user to overview all the dependencies and used languages of a module or a set of modules, to detect potential cyclic dependencies as well as to see detailed paths that form the dependencies. The tool can be invoked from the project pane when one or more modules are selected.


Version control

In MPS 2.0 the Merge Driver has been introduced to resolve merge conflicts inside MPS-specific files. In MPS 2.5 the Merge driver has been modified in order to handle merge conflicts in a more reliable way:

  • Merge driver is now handling .msd and .mpl files in addition to the model files
  • Model files are always kept in a valid state, even during merge conflict resolution
  • Merge dialog would appear each time you try to open a model with conflicts

Save Transient Models indicator

It's not a secret that you can save transient models during code generation for debugging purposes. In MPS 2.5 you can switch now on/off saving of transient models just by clicking onto a button in the status bar:


Debugging

Using MPS projectional editing functionality and improved debugger support it is possible to implement cell-based highlighting of DSL code instead of the usual single-line highlighting typical for text-based debuggers:


Java Debugger

In addition to changes in the general debugger framework a number of improvements were implemented for Java-specific debugging

  • "Copy value" popup menu action for inspected variables in the variables view
  • Special highligting for incorrectly placed breakpoints
  • Use Alt+F8 to copy selected code from the editor into the Evaluate window
  • High-level (Domain-specific) types and variable names are calculated for variables in the evaluation and watches windows. Low-level (java) types are shown in brackets.

Comfortable way to run MPS from MPS

A Run Configuration, which starts another instance of MPS from MPS, can now automatically open a selected project on start. You can either choose an arbitrary project path or open the current project that is already open in the current MPS instance.




Other

New Productivity Guide

Good command of the tools is undoubtedly one of the attributes of an efficient developer. MPS 2.5 can monitor your actions and give you statistics on how frequently you use its most prominent editing and refactoring capabilities. Go to Help | Productivity Guide to see how well you do. Additionally, we've prepared a list of a couple dozen tricks you could learn through the Tip of the Day window to become more fluent with the MPS editor.


Migration

If you already use MPS in your projects, you may benefit from reading our migration guide with detailed description of the migration process.

Distribution

One of the goals for MPS 2.5 release was making our platform modular. By exploring Plugins page in setting dialog it's easy to see increased number of plugin forming MPS 2.5 platform. If some plugins are not necessary for current tasks those plugins can be simply switched of increasing performance of the platform. Same trick can be used to create reduced IDE for some specific DSLs based on MPS.


MPS.Classpath module removed

There are four specific modules used to expose all available Java API of the platform and MPS as JavaStub models:

  • MPS.Core
  • MPS.Editor
  • MPS.Platform
  • MPS.Workbench

These modules were created as a substitution for the MPS.Classpath module that existed in previous versions. In essence, MPS.Classpath has been split into these four modules to isolate the core functionality from any dependencies on UI-/Editor-/Platform- specific APIs.