Child pages
  • What's new in MPS 2.5 M1

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


The Dependencies Analyzer can report dependencies among modules or models. It can be called from the main menu or from the popup menu of modules/models:

TODO (Vaclav): How is the Module Dependencies Tool different from the Dependencies ANalyzer?


The interactive report, shown in a panel at the bottom, allows the user to view usages of modules by other modules. The panel on the right side displays modules and models dependent on the module selected in the left-hand side list.

Unlike the Module Dependencies Tool, which is described below and which simply visualizes the dependency information specified in model properties, the Analyzer checks the actual code and performs dependency analysis. It detects and highlights the elements that you really depend on.

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.


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.

TODO (Vaclav): Refer to the build language docs

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.


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.

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.