Child pages
  • What's new in MPS 2.5 M1
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 62 Next »

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.

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:

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:

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.

Dependencies analyzer

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.

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.


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.

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.

Changes in the Refactoring language

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 init (e.g. ask and ask boolean) and keystroke has no effect. All this functionality should be moved to an action correspondent to the refactoring.

The following constructs have been added to the refactoring language:

  • is applicable refactoring<Refactoring>(target)
    returns true if the refactoring target corresponds to the current target (type, single/multiple) and applicable as in refactoring isApplicable method, and there is no refactoring that overrides current refactoring for this target.
  • execute refactoring<Refactoring>(target : project, parameters );
    executes the refactoring for the target with parameters
  • create refcontext<Refactoring>(target : project, parameters )
    create a refactoring context for the refactoring, target and fill parameters in context, this context then can be used for refactoring execution or for further work with parameters; UI is not shown during this call

It is necessary to manually migrate existing user refactorings. The migration consists of several steps:

  • create a UI action for the refactoring
  • copy the caption, create context parameters
  • add a refactoring keystroke with the newly created action to KeymapChangesDeclaration
  • create ActionGroupDeclaration for the refactoring that modifies the jetbrains.mps.ide.actions.NodeRefactoring action group at the default position
  • add an isApplicable clause to the action created; usually it is just is applicable refactoring< >() call
  • add an execute clause to the action created; all the parameter preparations that were in init of the refactoring should be moved here; at the end it is necessary to execute the refactoring with the prepared parameters (with execute refactoring< >(); statement)
  • remove all parameter preparation code from init of the refactoring, they are now prepared before the entry to init; you can still validate parameters and return false if the validation fails

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 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 in this node and so 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.

An example of using the SuppressErrorsAttribute attribute and the corresponding intention.

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

Extensions support

Extensions provide a possibility to extend certain aspects of a solution or a language, which are not covered by the standard language aspects and the plugin mechanisms.

Support for extensions exists in

  • languages
  • plugin solutions

Quick howto

  1. Create an extension point
  2. Create one or more extensions
  3. Both the extension point and the extension must be in the plugin model
    1. Each extension must provide a get method, returning an object
    2. Each extension may opt to receive the activate/deactivate notifications
    3. An extension may declare fields, just like classes can

Extension language

The language jetbrains.mps.lang.extension declares concepts necessary for building extensions.

Extension point

The ExtensionPoint concept represents an extension point. The extension object type must be specified as a parameter.

Extension

The Extension concept is used to create a concrete extension.

Accessing extension point

An extension point can be accessed by reference using extension point expression.

Accessing extension objects

An extension point includes a way to access all objects provided by its extensions.

Be Careful

Icon

Objects returned by the extensions have transient nature: they may become obsolete as soon as a module reloading event happens. It is not recommended to e.g. cache these objects. Instead is it better to get a fresh copy each time.

Java API

Extension points and extensions are managed by the ExtensionRegistry core component.

Showing the current status of Saving Transient Models in the status bar

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.

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. 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.

Custom persistence for MPS models

With the improved jetbrains.mps.lang.stubs language 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.

Make process improvements

mps.* ANT tasks were reimplemented to eliminate dependencies on the IntelliJ platform modules. This reduced the loading time and so speeded-up execution of mps.* tasks.

Collections language improvements

TODO

  • MutliForEachStatement
  • others?

Build language redesigned

TODO

  • ...
  • Cross-project variables support
  • Base-directory management in buildScript
  • Project dependency management

New Scopes

TODO

Version control

More reliable merge conflict handling with merge driver.

  • Automatic merge of project and .msd/.mpl files.
  • Merge driver tries to leaves models in working directory in readable state
  • Conflicted models are not opened from project tree. When you first try to open conflicted model you'll get merge dialog for this model.

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:

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:

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.

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.

Migration

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

  • No labels