MPS 2019.1ヘルプ

依存関係を正しくする

目的

Modules and models are typically interconnected by a network of dependencies of various types. Assuming you have understood the basic principles and categorisations of modules and models, as described at the MPSプロジェクト構造 page, we can now dive deeper as learn all the details.

Getting dependencies right in MPS is a frequent cause of frustration among inexperienced users as well as seasoned veterans. This page aims to solve the problem once and for all. You should be able to find all the relevant information categorised into sections by the various module and dependency types.

All programming languages have a notion of "imports". In Java you get packages and the "import" statement. In Ruby or Python you have "modules" and "require" or "import" statements. In MPS we provide a similar mechanism for packaging code and expressing dependencies in a way that works universally across languages - code is packages into models and these models can express mutual dependencies。

In addtion, since MPS is a multi-language development environment, models can specify the languages (aka syntaxes) enabled in them. This is different from when writing code in Java, Ruby or other languages, where the language to be used is given and fixed.

便利なキーボードショートカット

Whenever positioned on a model or a node in the left-hand-side プロジェクトツールウィンドウ or when editing in the editor, you can invoke quick actions with the keyboard that will add dependencies or used languages into the current model as well as its containing solution.

  • コントロール+ L - Add a used language

  • Control + M - 依存関係を追加する

  • Control/Cmd + R - Add a dependency that contains a root concept of a given name

  • Control/Cmd + Shift + A - brings up a generic action-selction dialog, in which you can select the desired action applicable in the current context

解決策

Solutions represent programs written in one or more languages. They typically serve two purposes:

  1. サンドボックスソリューション - これらのソリューションにはエンドユーザーコードが含まれています。IDEはコードを特別な方法で処理しません。

  2. ランタイム ソリューション - これらのソリューションには、他のモジュール（ソリューション、言語、またはジェネレータ）が依存するコードが含まれています。コードはMPSモデルとJavaクラス、ソースまたはjarファイルで構成できます。IDEは、クラスがコンパイルまたは外部で変更されるたびに、クラスをリロードします。

  3. プラグインソリューション 秒 - これらのソリューションは何らかの方法でIDE機能を拡張します。それらは新しいメニューエントリを提供したり、サイドツールパネルウィンドウを追加したり、プロジェクト設定ダイアログなどからカスタム設定画面を定義したりすることができます。繰り返しますが、MPSはクラスが変更されるたびにリロードし続けます。さらに、IDE機能もそれに応じて更新されます。

We'll start with the properties valid for all solutions and then cover the specifics of runtime and plugin solutions.

Solution1

共通

プロパティー

  • 名前 - name of the solution

  • ファイル・パス - path the the module file

  • ジェネレーター出力パス - points to the folder, where generated sources should be placed

  • Left-side panel - contains model roots, each of which may hold one or more models。

  • Right-side panel - displays the directory structure under the model root currently selected in the left-side panel. Folders and jar files can be selected and marked/unmarked as being models of the current model root。

Model root types

Solutions contain model roots, which in turn contain models. Each model root typically points to a folder and the contained models lie in one or more sub-folders of that folder. Depending on the type of contained models, the model roots are of different kinds:

  • default - the standard MPS model root type holding MPS models

  • java_classes - a set of directories or jar files containing Java class files

  • javasource_stubs - a set of directories or jar files containing Java sources

依存関係

The dependencies of a solutions are other solutions and languages, the models of which will be visible from within this solution.

The エクスポート flag then specifies whether the dependency should be transitively added as a dependency to all modules that depend on the current solution. For example, of module A depends on B with export on and C depends on A, then C depends on B.

使用言語

The languages as well as devkits that the solution's models may use are listed among used languages. Used languages are specified on the model level and the 使用言語 tab on modules only shows a collection of used languages of its all models.

Java

This is where the different kinds of Solutions differ mostly.

The Java tab contains several options:

  • Solution kind - different kinds of solutions are treated slightly differently by MPS and have access to different MPS internals

    • なし - default, used for user code, which does not need any special class-loading strategy - use for サンドボックスソリューション

    • その他 - used by typical libraries of reusable code that are being leveraged by other languages and solutions - use for Runtime solutions

    • Core plugin - used by code that ties into the MPS IDE core and needs to have its class-loading managed accordingly - use for Plugin solutions

    • Editor plugin used by code that ties into the MPS editor and needs to have its class-loading managed in sync with the rest of the editor- use for Plugin solutions that only enhance the editor

  • Compile in MPS - indicates, whether the generated artifacts should be compiled with the Java compiler directly in MPS and part of the generation process

  • ソース・パス - Java sources that should be made available to other Java code in the project

  • ライブラリー - Java classes and jars that are required at run-time by the Java code in one or more models of the solution

ファセット

  • Idea Plugin - checked, if the solution hooks into the IDE functionality

  • Java - checked, if the solution relies on Java on some way. Keep this checked in most cases.

  • tests - checked, if the solution contains test models

Solution models

Solutions contain one or more models. Models can be mutually nested and form hierarchies, just like, for example, Java packages can. The properties dialog hides a few configuration options that can be tweaked:

Model1

依存関係

Models from the current or imported modules can be listed here, so that their elements become accessible in code of this model.

Used languages

The languages used by this model must be listed here.

拡張

A few extra options are listed on the Advanced tab:

  • Do not generate - exclude this model from code generation, perhaps because it cannot be meaningfully generated

  • ファイル・パス - location of the model file

  • Languages engaged on generation - lists languages needed for proper generation of the model, if the languages are not directly or indirectly associated with any of the used languages and thus the generator fails finding these languages automatically

Virtual packages

Nodes in models can be logically organised into hierarchies of virtual packages. Use the Set Virtual Package option from the node's context pop-up menu and specify a name, possibly separating nested virtual folder names with the dot symbol.

Adding external Java classes and jars to a project - runtime solutions

Runtime solutions represent libraries of reusable code in MPS. They may contain models holding MPS code as well as models referring to external Java sources, classes or jar files. To properly include external Java code in a project, you need to follow a few steps:

  1. Create a new Solution

  2. In the Solution properties dialog ( Alt + Enter ) specify the Java code, such that:

    1. 「共通」タブ - click on Add Model Root , select javaclasses for classes or jars, select javasource_stubs for Java sources and navigate to your lib folder.

    2. Select the folder(s) or jar(s) listed in the right-side panel of the properties dialog and click on the blue "Models" button.

    3. Also on the Javaタブ add all the jars or the classes root folders to the ライブラリー part of the window, otherwise the solution using the library classes would not be able to compile. When using java_sourcestubs, add the sources into the ソース・パス part of the Javaタブ window, instead.

  3. A new folder named stubs should appear in your solution

  4. Now after you import the solution into another module (solution, language, generator) the classes will become available in that module's models

  5. The languages that want to use the runtime solution will need to refer to it in the Runtime Solutions section of the ランタイム tab of their module properties

言語

Languages represent a language definition and consist of several models, each of which represent a distinct aspect of the language. Languages also contain a single 生成プログラム module. The properties dialog for languages is in many ways similar to the one of 解決策 . Below we will only mention the differences:

Language1

共通

A language typically has a single model root that points to a directory, in which all the models for the distinct aspects are located.

依存関係

The dependencies of a language are other solutions and languages, the models of which will be visible from within this solution. The エクスポート flag then specifies whether the dependency should be transitively added as a dependency to all modules that depend on the current language.

A dependency on a language offers thee スコープ options:

  • デフォルト - only makes the models of the other language/solution available for references (aggregation)
    The structure aspects manifest languages they incorporate by aggregation (i.e. using a foreign concept in a child role), there's no need to import such languages explicitly into a model that uses the aggregating language or to 'extend' language modules.

  • 拡張 - allows the language to define concepts extending concepts from the there language

  • 生成ターゲット - specifies that the current language is generated into the other language, thus placing a generator ordering constraint that the other language must only be generated after the current one has finished generating

使用言語

This is the same as for solutions.

ランタイム

  • Runtime Solutions - lists solutions of reusable code that the language requires. See the " Adding external Java classes and jars to a project - runtime solutions " section above for details on how to create such a solution.

  • アクセサリーモデル - lists accessory models that the language needs. Nodes contained in these accessory models are implicitly available on the Java classpath and the 依存関係 of any model using this language.

Java

This is the same as for solutions, except for the two missing options that are not applicable to languages.

ファセット

This is the same as for solutions.

Language models/aspects

Dependencies / Used Languages / Advanced

These settings are the same and have the same meaning as the settings on any other models, as described in the 解決策 section.

生成プログラム

The generator module settings are very similar to those of other module types:

Generator1

共通

This is the same as for languages.

依存関係

This is the same as for solutions. Additionally generator modules may depend on other generator modules and specify スコープ :

  • デフォルト - only makes the models of the other language/solution available for references

  • 拡張 - the current generator will be able to extend the generator elements of the extended generator

  • デザイン - the target generator is only needed to be referred from a priority rule of this generator

使用言語

This is the same as for languages.

Generators priorities

This tab allows to define priority rules for generators, in order to properly order the generators in the generation process. Additionally, three options are configurable through the check-boxes at the bottom of the dialog:

  • Generate Templates - indicates, whether the generator templates should be generated and compiled into Java, or whether they should be instead interpreted by the generator during generation

  • Reflective queries - indicates, whether the generated queries will be invoked through Java reflection or not. (Check out the Generator documentation for details)

  • IOperationContext parameter - indicates, whether the generator makes use of the operationContext parameter passed into the queries. The parameter will be removed in the future and generators should gradually stop using it.

Java

This is the same as for languages.

ファセット

This is the same as for languages.

Generator models

This is the same as for solutions.

最終更新日: 2019年4月12日
依存関係依存関係アナライザー - モデルの依存関係を分析する