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.
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.
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. We recommend that you use this new language instead of the old ones, if you need to work with XML in MPS. All the other XML languages will be deprecated in the future.
In order to make the structure of MPS core languages more consistent and clear, the Refactoring language has been changes considerably. Several new and easy-to-use constructs have been added and parts of the functionality was deprecated and moved into the Actions language.
The UI for retrieving the refactoring parameters has been removed from the refactoring language. Choosers for parameters are no longer called, it is not allowed to show UI in
ask boolean) and keystroke has no effect. All this functionality should be moved to an action corresponding to the refactoring.
The following constructs have been added to the refactoring language. These new constructs are intended to to be used from code, typically from within the actions:
is applicable refactoring<
isApplicablemethod, and there is no refactoring that overrides current refactoring for this target.
It is necessary to manually migrate existing user refactorings. The migration consists of several steps:
isApplicableclause to the action created; usually it is just
is applicable refactoring< >
executeclause to the action created; all the parameter preparations that were in
initof the refactoring should be moved here; at the end it is necessary to execute the refactoring with the prepared parameters (with
execute refactoring< >
initof the refactoring, they are now prepared before the entry to
init; you can still validate parameters and return false if the validation fails
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.
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.
TODO: a screen-shot ?
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.
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:
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.
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.
Module Dependency Tool shows all transitive dependencies of the modules in the left panel. Optionally it can also display all directly or indirectly used languages. It is possible to expand any dependency node and get all dependencies of the expanded node as children. These will again be transitive dependencies, but this time for the expanded node.
Select one or more of the dependency nodes in the left panel. The right panel will show paths to each of the selected modules from its "parent" module. You can see a brief explanation of each relation between modules in the right tree. The types of dependencies can be one of: depends on, uses language, exports runtime, uses devkit, etc. For convinience the name of the target dependent module is shown in bold.
There are two types of dependency paths: Dependency and Used Language. When you select a module in the Used Language folder in the left tree, the right tree shows only the dependency paths that introduce the used language relation for the given module. To show "ordinary" dependencies on a language module, you should select it outside of the Used Languages folder (e.g. the jetbrains.mps.lang.core language in the picture below). It is also possible to select multiple nodes (e.g. the same language dependency both inside and outside of the Used Language folder). In that case you get a union of results for both paths.
When you are using a language that comes with its own libraries, those libraries are typically not needed to compile your project. It is the runtime when the libraries must be around for your code to work. For tracking runtime dependencies in addition to the "compile-time visible" ones, you should check the Runtime option in the toolbar. The runtime dependencies are marked with a "(runtime)" comment.
The default order for dependency paths is by their length starting from the shortest. However, there are paths that cannot be shown - paths that have the same tail part as one of the already shown path. It is still possible to display all such paths in the right tree with the "Show all paths" option. For these only the starting (distinct) part of the path is shown, while the symbols "... -->" mean that there is already a path shown in the tree somewhere above that describes the rest of the dependency path. You can follow the path by double-clicking its last element.
The modules in the left tree that participate in dependency cycles are shown in red color. It is possible to see paths forming the cycle by selecting the module dependency that refers to the parent or, for the user convinience, by using the popup menu:
For some types of dependencies the pop-up menu offers the possibility to invoke convenience actions such as Show Usages or Safe Delete. For the "depends on" dependencies (those without re-export) Dependencies Analyzer will be invoked for the Show Usages action.
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 enables the developers to suppress the reported problems directly in the editor (and in the model checker).
If a node is an instance of a concept, which implements the ISuppressErrors interface, all issues on this node and all its children won't be shown. For example, comments in BaseLanguage implement ISupressErrors. It is also possible to define child roles, in which issues should be suppressed, by overriding the boolean method suppress(node<> child) of the ISupressErrors interface.
Additionally, if a node has an attribute of a concept that implements ISuppressErrors, issues in such node will be suppressed too. There is a convenience default implementation of an ISuppressErrors node attribute called SuppressErrorsAttribute. It can be applied to only those nodes that are instances of ICanSuppressErrors.
One place where this feature is also useful are the generators, since type errors, for example, are sometimes unavoidable in the templates.
There is an error in editor:
BaseLanguage Statement implements ICanSuppressErrors, so the user can apply the highlighted intention here:
Now the error isn't highlighted any longer, but there is a newly added cross icon in the left pane. The SuppressErrorsAttribute can be removed either by pressing that cross or by applying the corresponding intention
A button in the status bar allows the user to enable and disable saving of transient models with one click.
If transient nodels saving is enabled, this button shows a notification popup when generation starts.
The popup notification can be disabled in Settings -> IDE Settings -> Notifications -> Saving Transient Models Is On.
More reliable merge conflict handling with the MPS merge driver:
In order to make MPS more modular, the debugger API and the Java debugger itself were moved into separate MPS plugins. This allows the user to completely turn the functionality off when not needed. A migration script to upgrade code to the new debugger API has been included in the MPS 2.5 migration wizard. Additionally, a migration script named "Fix references to debugger classes" is available for manual execution.
New debugger features introduced in MPS 2.5:
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. In the Latter case, the project file is copied into a temporary directory to avoid collisions between the two running instances.
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:
Additionaly, 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:
There are four specific modules used to expose all available Java API of the platform and MPS as JavaStub models:
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.
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.
If you already use MPS in your projects, you may benefit from reading our migration guide with detailed description of the migration process.