MPS plugin for IntelliJ IDEA
MPS 2.5 can be run as a plugin for IntelliJ IDEA enabling MPS-based DSLs to be used directly in a Java IDE and so interoperate tightly with the Java code. Custom languages can be exported from MPS as IDEA plugins as well. IntelliJ IDEA became another platform for MPS-based DSLs use, besides standalone Java applications and MPS itself.
There are several aspects of integrating MPS into IntelliJ IDEA:
- MPS Facet + settings (model roots/used languages/output path/...)
- Explore .mps files in IDEA project view -> double-click on root to open editor
- Change model properties (imported models/used languages) by calling popup menu on model file
- Generating code by making the project
- navigate to errors in DSL code reported by generator (make)
- see http://confluence.jetbrains.net/display/MPSInt/MPS+Make+In+IDEA
- two modes of generating files: to different source root or to the same folder next to .mps file
- hiding generated code
- Debugger in IDEA plugin: put a breakpoint into DSL code, run java application and stop on this breakpoint & explore stack trace
- VCS integration
- Actions available in the IDEA plugin
- Navigate to model/module/root (Alt+F1) is similar to MPS
- create complete list?
- Two aspects of working with MPS plugins for IDEA:
- deploying your own languages
- using one of languages distributed with MPS
- MPS plugin distribution description (plugins + possibility to switch then on/off)
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 Refactoring language
UI for getting refactoring parameters now is removed from refactoring language. Now choosers for parameters are not called, it is not allowed to show UI in
ask boolean), keystroke has no effect. All this functionality should be moved to an action correspondent to the refactoring.
The following constructs added to the refactoring language:
is applicable refactoring<
returns true if refactoring target corresponds to the current target (type, single/multiple) and applicable as in refactoring
isApplicablemethod, and there is no refactoring that overrides current refactoring for this target.
executes refactoring for target with parameters
create refactoring context for 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 user refactorings. Migration consists of
- create action for refactoring
- copy caption, create context parameters
- add refactoring keystroke with the newly created action to KeymapChangesDeclaration
- create ActionGroupDeclaration for refactoring that modifies jetbrains.mps.ide.actions.NodeRefactoring action group at default position
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 refactoring should be moved here; at the end it is necessary to execute refacoring with prepared parameters (with
execute refactoring< >
- remove all parameter preparation from
initof refactoring, they should be ready on entry to
init; you can still validate parameters and return false if validation fails
It is possible to suppress errors in editor (and in model checker) now.
If node is instance of a concept which implements ISuppressErrors interface, then all errors in this node and it's children won't be shown. For example comments in baseLanguage implement ISupressErrors.
It is also possible to define child roles, where errors should be suppressed, by overriding interface boolean method suppress(node<> child).
Also if node has attribute of concept implementing ISuppressErrors, errors in such node will be suppressed too.
There is default implementation of ISuppressErrors node attribute. It can be applied only to nodes that are instances of ICanSuppressErrors.
Here is an example of using this attribute and corresponding intention:
There is an error in editor:
BaseLanguage Statement imlpements ICanSuppressErrors, so user can apply highlighted intention here:
Now the error isn't highlighted, but there is a cross icon in the left pane. SuppressErrorsAttribute can be removed either by pressing on that cross or by applying corresponding intention
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
- plugin solutions
- Create an extension point
- Create one or more extensions
- Both must be in the plugin model
- Each extension must provide a get method, returning an object
- Each extension may opt to receive activate/deactivate notifications
- An extension may declare fields, just like class
The language jetbrains.mps.lang.extension declares concepts necessary for building extensions.
ExtensionPoint concept represents an extension point. The extension object type must be specified as a parameter.
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.
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
Custom persistence for MPS models
Make process improvements
- Faster ANT generate task; no dependencies on the idea platform
- Table selection improvements (check if it was done in 2.5)
- Table column selection
- .hash# files are not generated anymore
- new generator macros (if any?)
Collections language improvements
Build language redesigned
- Cross-project variables support
- Base-directory management in buildScript
- Project dependency management
MPS.Classpath was split into: MPS.Core, MPS.Editor, MPS.Platform and MPS.Workbench
- Moving code from plug-in aspect to separate solutions
- Solution types (plug-in/core/editor)
More reliable merge conflict handling
- MPS plugin structure/ability to switch on/of some parts of MPS by disabling plugins.