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 35 Next »

Dependencies analyzer

Dependencies analyzer can be called from main menu or from popup menu on a set of modules/models::

          

The lower panel shows usages of items selected in the right panel in the left tree scope selection 

Module Dependencies Tool

With this tool it is possible to overview all the module (or set of modules) dependencies and used languages, detect cyclic dependencies as well as see in details paths that lead to the given dependency. The tool can be invoked from the project pane when one or more modules selected there.


Module Dependency Tool shows in the left panel all transitive dependencies of module and optionally all used (directly or indirectly) languages. It is possible to expand any dependency node and get all dependencies of the expanded node as children. These will be again transitive dependency but for the expanded node.

Select one of dependency nodes or set of nodes in the left panel. Right panel shows paths to the each selected module from its "parent" module. You can see brief explanation of each relation between modules in the right tree. It can be 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 module in the Used Language folder in the left tree right tree shows only dependency paths making "used language" relation for the given module. To show "ordinary" dependencies on language as a module you should choose it out of Used Languages folder (like jetbrains.mps.lang.core in the picture below). It is possible to select several nodes (e.g. the same language dependency inside and outside Used Language folder), then you get union of paths.

If you want to track not only "visible" but also runtime dependencies you should check "runtime" option in toolbar. Only runtime dependencies are marked with "(runtime)" comment in the left tree.

By default dependency paths are shown in "from the shortest to longest" order. But there are still paths that are not shown: paths with the same tail part as one of the already shown path. It is still possible to see all such paths in the right tree with the "Show all paths" option. Only starting (distinct) part of path is shown, symbols "... -->" mean that there is continueation of the path already shown in the tree; you can follow path by double clicking its last element.
Modules participating in dependency cycles are shown in red color in the left tree. It is possible to see paths in cycle by selecting module dependency equal to parent or for convinience by using popup menu: 

For some types of dependencies it is possible to show usages or safe delete with popup menu. For "depends on" (dependency without re-export) Dependencies Analyzer will be invoked on Show Usages.

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 init (e.g. ask and 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<Refactoring>(target)
    returns true if 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 refactoring for target with parameters
  • create refcontext<Refactoring>(target : project, 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
  • add isApplicable clause to the action created; usually it is just is applicable refactoring< >() call
  • add execute clause to the action created; all the parameter preparations that were in init of refactoring should be moved here; at the end it is necessary to execute refacoring with prepared parameters (with execute refactoring< >(); statement)
  • remove all parameter preparation from init of refactoring, they should be ready on entry to init; you can still validate parameters and return false if validation fails

Suppressing errors

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 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 must be in the plugin model
    1. Each extension must provide a get method, returning an object
    2. Each extension may opt to receive activate/deactivate notifications
    3. An extension may declare fields, just like class

Extension language

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

Extension point

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

Extension

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.

  • No labels