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 by conventions (e.g. the file extension).
便利なキーボードショートカット
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.
ランタイム ソリューション - これらのソリューションには、他のモジュール（ソリューション、言語、またはジェネレーター）が依存するコードが含まれています。コードは、MPS モデルと、Java クラス、ソース、または jar ファイルで構成できます。IDE は、クラスが外部でコンパイルまたは変更されるたびに、クラスを再ロードします。
プラグインソリューション - these solutions extend the IDE functionality in some way. They can contribute new menu entries, add side tool panel windows, define custom preference screens fro the Project settings dialog, etc. Again, MPS will keep reloading the classes, whenever they change. Additionally the IDE functionality will be updated accordingly.
左側パネル - contains model roots, each of which may hold one or more models.
右側パネル - 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.
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 Used Languages 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.
Libraries - Java classes and jars that are required at run-time by the Java code in one or more models of the solution
ファセット
Custom Generation - allows attaching a generator plan to the module. More on explicit generator plans is to be found at the Generator plans documentation.
アイデアプラグイン - 解決策が IDE 機能にフックする場合はチェック
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
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.
プロジェクトへの外部 Java クラスと jar の追加 - ランタイムソリューション
Runtime solutions represent libraries of reusable code in MPS. They may contain models holding MPS code as well as stub models that refer to external Java sources, classes or jar files. To properly include external Java code in a project, you need to follow a few steps:
Create a new Solution in your project.
Copy the desired jar files, classes or Java sources into a directory under the solution's root folder, such as "/libs".
In the Solution's properties dialog ( Alt+Enter ) attach the Java code. This requires a few steps:
First, in the left-hand side panel of the 「共通」タブ , which is used to manage model roots (i.e. locations of models that belong to the module), delete the existing model root unless you want to preserve or create code that you write in MPS as part of your runtime library.
Second, also in the 「共通」タブ , click on Add Model Root, select javaclasses for classes or jars, select javasource_stubs for Java sources and navigate MPS to your lib folder. This will add a new entry into the list of model roots. This entry will represent the "libs" folder
Third, when the new model root is selected in the left-hand side panel, select the folder(s) or jar(s) listed in the right-side panel of the properties dialog and click on the blue "Models" button at the top of the right-hand side panel. The selected folders and jars will be shown with a blue icon next to them in the right-hand side panel.
Switch to the 依存関係 tab and add the JDK solution as a dependency. Do not forget to turn on the エクスポート flag. This will allow your jar files to refer to the JDK classes.
Then head to the Java タブ to 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. Also add any dependencies of the libraries that you have added to the module.
Additionally, set ソリューションの種類 to その他 to have MPS reload the classes properly.
A new folder named stubs should appear in your solution.
Now after you import the solution into another module (solution, language, generator) the classes will become available in that module's models.
The languages that want to use the runtime solution as a runtime dependency of the code that gets generated by the language's generator will need to refer to it in the ランタイムソリューション section of the ランタイム tab of their module properties.
Include the runtime jars in the build models - If you use the MPS build scripts to build a plugin with your languages you should also package the runtime libraries in the plugin by copying them into the desired location within the target layout definition.
If you forget to do so, you'll be getting errors like "No such path in local layout" when rebuilding the build script's model.
言語
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:
Default- 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.
Extends - allows the language to define concepts extending concepts from the there language
ランタイムソリューション - 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 Dependencies of any model using this language.
Default - only makes the models of the other language/solution available for references
Extends - the current generator will be able to extend the generator elements of the extended generator
Design - the target generator is only needed to be referred from a priority rule of this generator
使用言語
これは言語の場合と同じです。
ジェネレーターの優先順位
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:
IOperationContext パラメーター - 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.
