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.
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.
We'll start with the properties valid for all solutions and then cover the specifics of runtime and plugin solutions.
When included in the project as models, Java classes in directories or jar files will become first-class citizens of the MPS model pool and will become available for direct references from other models, which import these stub models. A second option to include classes and jars in MPS is to use the Javaタブ and define them as libraries. In that case the classes will be loaded, but not directly referenceble from MPS code. This is useful for libraries that are needed by the stub models.
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.
This is where the different kinds of Solutions differ mostly.
Java - checked, if the solution relies on Java on some way. Keep this checked in most cases.
Models from the current or imported modules can be listed here, so that their elements become accessible in code of this model.
The languages used by this model must be listed here.
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.
「共通」タブ - click on Add Model Root , select javaclasses for classes or jars, select javasource_stubs for Java sources and navigate to your lib folder.
Select the folder(s) or jar(s) listed in the right-side panel of the properties dialog and click on the blue "Models" button.
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.
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.
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.
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.
This is the same as for solutions, except for the two missing options that are not applicable to languages.
When using a runtime solution in a language, you need to set both the dependency in the 依存関係 tab and the Runtime Solutions on the ランタイム tab.
These settings are the same and have the same meaning as the settings on any other models, as described in the 解決策 section.
This is the same as for languages.
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.