移行ガイド
新しいバージョンの MPS でプロジェクトを開くと、そのバージョンの MPS に付属するすべての自動移行スクリプトが実行され、プロジェクトが言語と API で最新の状態になります。追加の手動手順が必要になる場合や、ユーザーが特別な注意を払う必要がある場合があります。このページには、MPS の過去のバージョンごとにそのような手順がリストされています。
MPS バージョンを更新する前に、プロジェクトに対して更新前チェックを実行することをお勧めします。更新前チェックアクションは、メインメニューから開始できます。移行 | 更新前チェックメニュー項目を実行します。これを古い MPS インスタンスで実行して、新しいバージョンの MPS で問題が発生する可能性がある、移行されていない残り物がプロジェクトにないことを確認します。つまり、プロジェクトで使用されている言語のすべての移行スクリプトのすべての check() メソッドを呼び出します。アクションは、これらのケースで考えられるすべての問題を修正しようとします。
古い言語バージョンを使用して作成された新しいノードは、移行されていないブランチから移行されたブランチにマージされました。
一部のノードは完全に移行されませんでした。これは通常、移行が複雑すぎるために移行を断念し、代わりにこれらのノードを手動で移行することを推奨したためです。
MPS 2023.3 への移行
スタブモデルのメソッドノード ID から戻り値の型をクリアする
MPS は、java スタブノード ID の一部としての戻り値の型の書き込みを停止しました。戻り値の型を含む古い永続形式をまだ使用している java スタブ ID の残りのケースを削除する移行が追加されました。
実行時に ${module} マクロを使用しないでください
実行時、デプロイされたモジュールの「${module}」マクロは module.jar ファイルに解決されなくなり、代わりに module-src.jar に解決されます。一般に、このマクロは実行時には使用されません。実行時リソースにアクセスするには、より良い方法があります (例: モジュール ClassLoader 経由)。
スタブは MPS.Core によって公開されなくなりました
MPS.Core は gnu.trove および org.jdom のスタブを公開しなくなりました。
ReloadableSModule は SModule の拡張を停止する
クラスロードのストーリーを改善するための継続的な取り組みとして、次のアクション項目をお勧めします: ReloadableSModule が SModule を拡張すると想定しないでください。これらの 2 つのインターフェースは、次のバージョンの 1 つで分離される予定です。
スタンドアロン IDE で新しい UI プロモーションバナーを無効にする
MPS は新しい UI をサポートするようになったため、スタンドアロン IDE は最初の起動時に、新しい UI を有効にするかどうかをユーザーに確認します。スタンドアロン IDE のほとんどは新しい UI 視覚要素をすべてサポートしていない可能性があるため、ユーザーが誤って新しい UI をオンにしないように、この新しいバナーを無効にすることをお勧めします。
バナーは、スタンドアロン IDE プロセス (mps.sh または mps.bat) を開始するスタートアップスクリプトにプロパティ -Dexperimental.ui.used.once を追加することで無効になります。新しく生成された IDE では、このプロパティがジェネレーターによって設定されます。既存のスタートアップスクリプトは、手動で変更するか、MPS の新しいバージョンで再生成する必要があります。
一方、スタンドアロン IDE のユーザーに対してバナーを有効にしたい場合は、ビルドスクリプトからプロパティを手動で削除します。
従来の Java スタブメソッド参照の互換モードが削除されました
MPS 2023.3 は最終的に、戻り値の型が含まれる従来の Java スタブメソッド参照の互換モードを削除しました。2019.1 以来、MPS は戻り値の型のないスタブノード ID を使用してきました。当時の MPS には移行が含まれていましたが、移行されていない古いブランチが統合されたため、いくつかの参照が紛れ込んでいた可能性があります。このような場合、プロジェクトの移行は、プロジェクトに適用する移行アシスタントの移行リストに含まれ、さらに、プロジェクトは移行するまでコンパイルできなくなります。互換モードが削除されたため、移行の事前チェックでエラーが発生する場合もあります。これらを無視して移行を続行してください。
MPS 2023.2 への移行
拡張言語 / ターゲット言語の拡張概念を使用する
jmlang.generator.plan 言語での移行では、Transform ステートメントの新しい拡張バージョン (ジェネレーターグループ化をサポートするバージョン) を使用するように、node<Plan> インスタンスが更新されます。これにより、指定された言語を対象とする言語が減ります (一種の「以前の」もの)。より優先順位ルール、特定のステップにバインドされている)、指定された言語を拡張する言語。この機能は古い制限付き変換と並行して存在していましたが、より洗練された変換に進むことをお勧めします。
Java モジュールファセット設定はモジュールのクラスロードを管理する
(MPS-20726 に対処するため) モジュールプロパティ (.mpl/.msd/.mpst ファイルに保存されている) を改善し、モジュールファセットに従って構造化するという、MPS 2022.3 で開始された取り組みを継続します。MPS 2023.3 では、従来のモジュールプロパティの compileInMPS および pluginKind は記述子ファイル内でシリアル化されなくなり、MPS は Java モジュールファセット設定のみに依存してモジュールのクラスロードを管理します。
移行を適用した後、MPS を再起動する
複数の所有者を持つモジュールは自動的に再ロードされないため、移行の実行後に再起動が必要になる場合があります。
Java ファセットで Java 固有のモジュール設定を保持する
モジュールの Java 設定を Java モジュールファセットに保持するための継続的な取り組みで、追加のソースパスと java ライブラリの値が、モジュール記述子の永続化の <facet> 要素に格納されるようになりました。この移行により、すべての値が ".msd/mpl (solution/sourcePath/source)" の古い場所から "solution/facets/facet[@type="java" ]/source" に、"solution/stubModelEntries/stubModelEntry" から "solution/facets/facet[@type="java" ]/library" に移動します。この変更により、パス指定で使用されるマクロ / 変数のパスに関するより多くの情報を保持できるようになり、複数のパス変数が同じパスに解決される場合に元の値を保持できるようになりました。エンドユーザーにとって目に見える変更はこれだけです（モジュールのプロパティダイアログでは、ソース / ライブラリのパスに加えて、記述子からマクロ名とその元の値がツールチップとして表示されます）。
データフローラーンタイムスタブ参照 MPS.Core を通常のノードに置き換える
データフロー言語のランタイムは、MPS.Core を通じて公開されていましたが、通常の MPS モジュール jmdataFlow.runtime が利用可能であり、実際にスタブを使用する必要はありません。MPS.Core を通じて公開することについてはメンションしていません。(MPS にはそのような使用箇所がありましたが、「コア」をさまざまな特定の言語やフレームワーク (パターン、移行、リファクタリング、データフローなど) から独立させておくため、これらの使用箇所は排除しました)。この移行は基本的に、すべての dataFlow.runtime スタブ参照を MPS.Core 経由で jmdataFlow.runtime のそれぞれのノードに再ルーティングします。
アクションのスレッドが更新されました
適切な更新スレッドを推測するための lang.plugin アクションの移行が追加されました。次の 2 つのオプションのいずれかを選択します。
Background(ActionUpdateThread.BGT)
EDT
EDT の一部のキーへのアクセスで問題が発生した場合は、ActionUpdateThread.OLD_EDT 値を使用する mps.actions.old_edt レジストリ設定を使用し、「バックグラウンドでの更新:」を false に設定して、移行が行われていないかどうかを確認してみてください。あなたのアクションに合わせてこれらのいずれかを変更してください。
言語およびソリューションプロバイダーを使用してモジュールを作成する
モジュールを作成 / 構成する従来のコード (AbstractModuleCreationDialog、AbstractModuleCreationSettings など ) はなくなりました。代わりに LanguageProducer/SolutionProducer を使用してください。
言語ランタイム統合コード用の別個のジェネレーター
jmlang.structural 言語には、言語ランタイム (別名「@descriptor」モデル) 統合コード用の別個のジェネレーターが含まれるようになりました。これは、言語アスペクト宣言を改善するための継続的な取り組みです。
TODO ツールの新しいホーム
ToDo ツールは mps-workbench の専用モジュール (別名 jmide module) に移動し、他のツールや言語 IDE 統合 (typesystem や module など) とともに、新たに導入された別個のプラグイン Jetbrains.mps.ide の一部として利用できるようになりました。依存関係アクション)。RCP がこれらのツールを再利用する場合は、必ず新しいプラグインをディストリビューションに含めてください。
ビルドスクリプトのターミナルウィンドウに別れを告げましょう
UNIX システム MPS-36027 のターミナルツールウィンドウの問題を修正するために、プラットフォームが再パッケージ化されました。この変更には、RCP MPS-36088 のビルドウィザードによって生成されたビルドプロジェクトの変更が伴いました。ただし、RCP の既存のビルドプロジェクトにはこの変更が自動的に適用されず、ターミナルツールウィンドウを再度適切にパッケージ化するには手動による介入が必要です。
モデルを削除するための安全な削除オプションが RCP から削除されました
mps-rcp プラグインが既存のビルドスクリプトに追加されていない限り、カスタムビルドの MPS ベースの RCP (スタンドアロン IDE) でモデルを削除する場合、安全な削除オプションは使用できなくなりました。プロジェクトの構築ウィザードは、スタンドアロン IDE シナリオ用に新しく作成されたすべてのビルドスクリプトに依存関係として mps-rcp を追加します。言語設計者は、ビルドスクリプトから mps-rcp を削除することを選択できます。
コンソールから移行するときに既存の ant スクリプトを更新する
path.mps.ant.path クラスパスは、util.jar ではなく util-8.jar ファイルを参照するように更新する必要があります。
MPS 2022.3 への移行
Java モジュールのファセット設定
専用プロジェクトの移行では、Java モジュールファセットの設定が、記述子の周囲に散在する無関係な値ではなく、明示的な値としてモジュール記述子に保存されます (たとえば、compileInMps と pluginKind はモジュールの属性であり、外部クラスローディングは追加のモジュールファセットによって管理されていました)。
gnu.trove および org.jdom ライブラリを抽出する
プロジェクトの移行により、gnu.trove および org.jdom ライブラリが MPS.Core から抽出されます。これらのライブラリには 2 つの新しいスタブモジュールがあります。移行により、以前は MPS.Core を通過していたスタブクラスへの参照が新しいモジュールにリダイレクトされます。これらのモジュールは、必要に応じて MPS.Core とは別に使用できます。
ファセットの作成、TextGen および Generate の移動
Make ファセット、TextGen および Generate は、以前は jmlang.core 言語のプラグインアスペクトに存在していましたが、現在は専用モジュール jmmake.facets i> に移動されています。これらのファセットを参照すると、生成されたソースで Make ターゲット名が更新されていることに気付くかもしれません。可能性は低いですが、依存関係として TextGen/Generate を参照する場合は、カスタム Make Facet を使用してモデルのモデルインポートを調整する必要がある場合があります。
JNA ライブラリの更新
MPS のジェネリクスディストリビューションには、ネイティブ jna ライブラリの 2 つのバージョンが含まれるようになり、それぞれが /lib/jna/ フォルダーの個別のサブフォルダーに保持されます。
amd64 - Intel ベースの Mac コンピューター用
aarch64 - Apple ハードウェア Mac コンピューター用
スタンドアロン MPS IDE 用のビルドスクリプトを作成するビルドスクリプトウィザードでは、jna ライブラリの aarch64 バリアントを利用する追加の MPS-macos-aarch64.zip レイアウトがすでに提供されていますが、以前から存在していた他の 3 つのレイアウトは、新しい場所から対応する jna ライブラリを正しく含めるように更新されています。既存のビルドスクリプトを手動で更新して、jna ライブラリの場所の変更に対応し、新しいプラットフォームに応じてバイナリファイルのセットを調整します。
MPS 2022.2 への移行
列挙値の古い形式のサポートを停止する
構造言語の列挙型とその永続形式は多くのリリース前に変更されましたが、互換性の理由から古い形式がまだサポートされていました。このサポートは MPS 2022.2 で終了し、新しい形式のみをサポートします。これにより、モデルが MPS の以前のバージョンで適切に移行されていない場合、MPS 2022.2 でモデルを読み取るときに問題が発生する可能性があります。これを修正するには、MPS 2019.1 の構造言語に導入された移行「列挙プロパティの更新」を再実行します。MPS 2022.2 でプロジェクトを開く前に、古い MPS で移行を実行する必要があります。
MPS Kotlin 言語の更新
MPS Kotlin 言語の最近の改善を反映するために、自動移行が提供されています。
ステートメントのサポートは、IStatementHolder インターフェースで一般化されました。独自のステートメントを使用する他の概念は、この概念を使用するように移行されました。
文字列リテラルと複数行リテラルは、1 つの文字列リテラルの概念に統合されました。
関数宣言の継承修飾子 (final、abstract など) は、Inheritable インターフェースの使用により必須になりました。宣言はそれに応じて移行されます。
変数の分解のサポートは、IDeconstructingDeclarations インターフェースにグループ化されます。for ステートメントと lambda マルチパラメーターは、それを使用するために移行されます。
レシーバー型の概念は、ReceiverType 概念 (型を参照する式) を使用しなくなり、型を直接保持します。
Unsigned、Long、Integer リテラルの概念は、IntegerLiteral の概念 (ブールフラグを使用) にグループ化されました。さらに、負の数値リテラルはサポートされなくなり、単項マイナスの概念を使用して作成する必要があります。
JDK 17 の使用
MPS 2022.2 は JDK 17 で開発およびテストされているため、MPS の実行および MPS で構築されたスタンドアロン IDE の実行には JDK 17 を使用することをお勧めします。コードが Java リフレクション API を使用してアクセスしている可能性のあるさまざまなクラスの可視性に問題が発生する可能性があります。MPS の実行時に JDK クラスで解決したのと同じ方法で問題を解決できます。--add-opens JVM 引数を使用して、それぞれのパッケージを追加します。
ロギング構成の変更
log4j が廃止されたため、bin/log.xml 構成は使用されなくなりました。log.xml から設定を移行するメカニズムはないため、log.properies で設定を再作成するか、IDE アクションを使用してログを構成する必要があります。MPS は、デフォルトのログ構成に構成ファイルを使用しなくなりました (代わりにコードで実行されます)。コマンドラインスイッチを使用して、構成ファイルの使用を明示的にオンにする必要があります。手動で記述したログコードの場合、変更を最小限に抑えるために、log4j コードを jetbrains.mps.logging.Logger.getLogger (Class<>) に置き換えることをお勧めします。jetbrains.mps.baseLanguage.logging 言語のユーザーは、新しいテンプレートを使用してコードを再生成するだけで更新されるため、気にする必要はありません。
MPS.Core は関連のないスタブをエクスポートしなくなりました
MPS.Core は、MPS.Generator および MPS.Textgen から利用可能なスタブをエクスポートしなくなりました。MPS.Generator と MPS.TextGen は、1 年前に 21.2 で導入されました。これは、依存関係の焦点を維持し、MPS.Core が多くの無関係な機能を持つモンスター豚に成長するのを防ぐためです。いくつかのリリースでは、MPS.Core は、指定された MPS.Generator および MPS.TextGen スタブソリューションと共に、Generator および TextGen サブシステム用の java スタブをエクスポートしました。このリリースでは、分割を確定し、MPS.Core はこれらのサブシステムのスタブをエクスポートしなくなりました。MPS.Generator および MPS.TextGen スタブへの参照を再ルーティングするための再実行可能な移行があります。モデルがまだ MPS.Core ソリューションを介して Generator/TextGen スタブを参照している場合は、再度実行する必要がある場合があります。
ショートカットを登録する lang.plugin の新しい API
カスタムショートカットセットを宣言するか、アクションの既存のショートカットをオーバーライドすると、生成されたコードが変更されることがあります。これにより、生成されたコードが合理化され、簡素化されます。
誤った依存関係を修正する必要があります
「deps.cp」が変換時に実際のモジュールコンパイル依存関係のスナップショットを保持するという事実は、コンパイル時 (Java クラスパス) 依存関係を満たすために未使用の依存関係がモジュール / モデルに追加されたときに、ハック / 回避策を台無しにする可能性があります。代わりに、この依存関係を適切な方法で導入する必要があります (ほとんどの場合、これは使用中の言語のランタイムの構成ミスにすぎません)。
Make ファセットの pathToFile の変更
Make ファセットで、pathToFile(String,IFile) 関数パラメーターがなくなりました。非常に特殊なケースはほとんどなく、必要になる可能性はほとんどありませんでした。ただし、代わりに使用できる pathToFile(IFile, IFile) がすでにいくつかのリリースで提供されています。
アスペクト宣言の副概念
実験的: アスペクト宣言の「代理」概念。独自の側面を宣言すると、これらに気付く場合があります。これは意味のある @descriptor モデルに向けた作業です。MPS は現在、「構造」の側面にこれを採用しています。これが正しい (または間違っている) と思われる場合は、ご意見をお聞かせください。
ビルドスクリプトでの mpsCore インポート (MPS-34554)
MPS は、mpsCore プロジェクトとそれぞれのプラグインを mpsStandalone プロジェクトから再エクスポートするために使用されていました。RCP のビルドプロジェクトが mpsCore をバンドル / インポートするために使用されている場合、インポートが再度解決されるように、直接プロジェクトの依存関係を mpsCore に追加する必要があります。
ビルドスクリプトに必要な追加の依存関係
lib/util_rt.jar ファイルは、ビルド言語を使用してスタンドアロン IDE を作成する既存のプロジェクトの MpsStartupScript ルートのブートクラスパスに追加する必要があります。そうしないと、スタンドアロン IDE を起動しようとしたときに、次のような例外が発生する可能性があります。
VM オプションが変更されました
MPS IDE の起動に使用される VM オプションが変更されました。必要なすべての VM オプションを提供するには、スタンドアロン IDE の既存のビルドスクリプトを手動で更新する必要があります。不足しているすべての依存関係を追加するインテンションが進行中です。配置されるまでは、新しいビルドスクリプトを生成し、作成したばかりの MpsStartupScript ルートノードをビルドスクリプトにコピーするか、以下のオプションのリストを使用することをお勧めします。
実行構成を再作成する
MPS で Java プロセスを開始するために必要な VM オプションが変更されたため、既存の実行構成は機能しません。更新された VM オプションを自動的に継承する新しい実行構成を作成するか、実行構成の仮想マシンパラメーターフィールドの値を次のように更新することができます。
.
拡張言語からのみ許可されるエディターのヒント
以前のバージョンでは、エディターを定義してエディターヒントを割り当てるときに、MPS は単なる 'default' 依存関係を通じて利用可能な他の言語モジュールからのエディターヒントを許容していました。現在、MPS では、エディターが保持する言語によって明示的に「拡張」された言語からのエディターヒントのみをエディターが使用できるようになります。
古いカスタム VM オプションは削除する必要があります
ツールボックスから MPS 2021.2 EAP 2 をインストールした場合、次の 3 つのカスタム VM オプションが設定されている可能性があります。
これらのオプションは現在廃止されているため、削除することを強くお勧めします。「ヘルプ」メニューから「カスタム VM オプションの編集」を選択し、行を手動で削除するだけです。
非推奨の needNoWriteAction プロパティを accessMode に置き換える
ノードテストケースに新しい accessMode プロパティが追加されます。以前は、ノードテストは BaseTestBody の runWithinCommand メソッドまたは runWithinRead メソッドにラップされて実行されていました。現在、テストは accessMode プロパティの値に応じて、runWithinCommand メソッド、runWithinRead メソッド、またはラップなしで実行されます。ExecutionModeNodesTestCase の移行により、非推奨の needsNoWriteAction プロパティが削除され、以前の needsNoWriteAction の値に応じて accessMode プロパティが command または none に設定されます。
テスト言語のカスタム拡張機能と、独自のテストメソッドを提供するノードテストケースでは、ジェネレーターでカスタムテストメソッドのコードをロックで適切にラップすることに特別な注意を払う必要があります。ランタイムクラス BaseTestBody には、switch_Test2Method テンプレートスイッチで使用されるのと同じように使用される 2 つの追加メソッド runWithinCommand および runWithinRead が提供されるようになりました。
MPS 2021.3 への移行
ビルドスクリプトに log4j を追加する
以前のバージョンの MPS でビルドスクリプトウィザードによって作成されたビルドスクリプトでは、2021.3 で log4j jar ファイルを見つける際に問題が発生する場合があります。
この問題を解決するには、ビルドモデルの MpsStartupScript ノードのブートクラスパスセクションに lib/3rd-party-rt.jar を追加する必要があります。
MPS.IDEA の util.jar への参照を MPS.Boot に再ルーティングする
巨大なシングルポイントオブエントリスタブモジュール（MPS.Core など）を、狭い使用シナリオを対象とするスリムモジュールに置き換える途中で、MPS.Boot ソリューションを抽出しました。MPS の起動に関連するクラスと、MPS.IDEA にあった IDE 起動ロジックに関連するいくつかの IntelliJ スタブを保持します。移行は、ソリューション MPS.IDEA の対応するスタブモデルを指す参照を新しいスタブソリューションに再ターゲットします。
ToRemove と ScheduledForRemoval を非推奨に置き換える
ToRemove および ScheduledForRemoval アノテーションは両方とも非推奨のコードを示します。これらの代わりに標準の Deprecated アノテーションが使用されます。2 つのアノテーションのバージョンパラメーターは、Deprecated の "since" パラメーターに移行されます。移行は IBLDeprecatable のインスタンスに対してのみ機能します。
UI アクションに非同期更新メカニズムを採用する
UI アクションを非同期的に更新するために、IDEA プラットフォームに大きな変更が加えられました。アクションの状態を更新するために必要なデータは、非同期かつ独立して収集および消費されます。より応答性の高い UI と一般的なパフォーマンスの向上が約束されています。MPS は変更の採用を開始しました。DataProvider として機能する手書きのアクションコードまたはカスタム UI コンポーネントがない限り、何も気付かないはずです。jmlang.plugin から生成されたアクションは影響を受けません。MPS アクション /UI 抽象化に固執する場合、コードに追加の注意を払う必要はありません。ただし、IDEA の DataProvider/DataContext API を明示的に扱う場合 (DataProvider を実装するカスタム UI ビューを提供するなど)、追加の移行作業が必要になる場合があります。
モデルの読み込みの遅延
要求された場合にのみモデルをロードする実験的な機能があります。MPS は、モジュールがリポジトリに認識される (別名「接続」される) 瞬間に、すべてのモジュールのモデルをロードしていました。現在、モジュールをパブリッシュしてもそのモデルのロードは強制されません。モデルにアクセスする必要がある場合にのみ、MPS がモデルのロードを試みます。通常、これはモジュールが公開された直後に発生します。この変更は、モデルのライフサイクルをそのモジュールからより独立させるための最初のステップにすぎません。
注目すべき API の変更
UI: NewSolutionDialog は汎用の NewModule に置き換えられましたダイアログ
SModel:[openapi] SNode.setReference（SReferenceLink、SReference）は非推奨になり、いくつかの代替手段が利用可能になりました。
SModel:[impl] SNode.toString および node.presentation 操作
作成: いくつかの jmmake.* 言語のランタイムモジュールを変更します。カスタムメイクファセットを作成すると、それらに気付く場合があります。
BaseLanguage: 「[package]Classifier」参照表記のサポートが削除されました
MPS 2021.2 への移行
NodeTestCases には再生成が必要です
2021.2.6 にアップグレードする場合、正常に実行するには、すべての NodeTestCases を再生成する必要があります。そうしないと、次のような例外が発生します
暗黙の node.toString() を明示的な smodel 操作に置き換える
新しい node.presentation 操作と移行が jetbrains.mps.lang.smodel に導入されます。移行により、文字列連結 ("string" + node および node + "string") でのノードの使用が明示的な node.presentation 操作に置き換えられます。現時点では、この操作は、以前は node.toString() が行っていた getPresentation() 動作メソッドに委譲されます。MPS は toString() メソッド実装で getPresentation() 動作メソッドを使用しなくなったため、エンドユーザーにノードプレゼンテーションを表示する場合は、明示的なノード操作 (node.presentation、node.getPresentation()、またはその他のカスタマイズされた動作など) を使用することをお勧めします。
MPS.Core スタブモデルを個別のモジュールに分割する
MPS.Core モジュール（lib/mps-core.jar、lib/mps-generator.jar、および lib/mps-textgen.jar）を介して公開されるスタブモデルは、MPS.Generator と MPS.Textgen に分離されています。これは主に、ジェネレーターまたは textgenAPI を直接使用するユーザーに影響します。
自動移行は、影響を受けるスタブを使用して新しいモジュールから使用するように参照を更新するだけです。失敗した場合は、MPS.Generator と MPS.TextGen を手動でインポートしてから、コード補完ダイアログを使用してコードで適切なモジュールのクラスを選択する必要があります。
互換性のために、MPS.Core は引き続き jar を公開しますが、2021.3 では公開を停止します。
プラグイン記述子の配置
IntelliJ プラットフォームは、プラグイン記述子（plugin.xml ファイル）がプラグインレイアウトの特定の場所にある場合にのみプラグインをロードするようになりました。plugin_folder/lib/one_of_the_plugins.jar!/META-INF/plugin.xml 以前は、META-INF/plugin.xml はプラグインフォルダー内の任意の場所に配置できました。
プラグイン記述子がプラグインレイアウトの適切な場所に明示的に記載されていない限り、ビルドスクリプトの生成時に自動トランザクションによってプラグイン記述子が生成されます。必要な jar ファイルをプラグインレイアウトに追加し、プラグイン記述子を保持します。生成中に追加することを目的としたコードは、プラグインレイアウトの読み取り専用セクションに表示されます。
「プラグイン記述子レイアウトのオーバーライド」と呼ばれるインテンションが利用可能です。これを使用すると、ビルドスクリプト作成者がデフォルトの動作を独自の動作でオーバーライドできます。インテンションは、レイアウトの必要な部分を生成し、手動で編集できるようにします。
インスペクションは、プラグイン記述子がレイアウト定義で見つからない場合は常に警告を報告します。
MPS 2020.1 への移行
core.text 言語の改善
jetbrains.mps.core.text 言語が改善され、BaseLanguage のコメントに使用されるようになりました。CommentPart および TextCommentPart の概念は廃止されました。言語がこれらの非推奨の概念を利用している場合は、代わりに jetbrains.mps.core.text 言語の Text、Line、Word などの概念を使用することを検討してください。次に、TextCommentParts に保持されているテキストを Words および Lines のインスタンスに変換する移行を言語のユーザーに提供する必要があります。このような移行を実装する最も簡単な方法は、次のとおりです。
ラインをインスタンス化する
Word をインスタンス化する
Line.addTextElement() を使用して行に単語を追加します
Word.value プロパティを TextCommentLine のテキストに設定します
Word.normalize() メソッドを呼び出して、単語のテキストを単語に適切に分割し、すべて同じ行に属させます
新しい移行
MPS 2020.1 には、プロジェクトを最新バージョンの jetbrains.mps.baseLanguage、jetbrains.mps.lang.quotation、jetbrains.mps.lang.editor に更新する 4 つの移行が付属しています。
UpdateSingleLineCommentToUseLinePerComment は、SingleLineComment のインスタンスを更新して、コメントのテキストによる説明を保持するために別の子を使用します。コメントは 1 行のテキストしか保持できないため、移行では、複数行にまたがる 1 行のコメントを分割する必要があります。
MigrateTryStatement は、TryCatchStatement および TryFinallyStatement のインスタンスを TryUniversalStatement に更新します。これにより、単一の catch 句での複数の例外や with-resource 機能などの JDK8 機能が可能になります。
LightQuotation_InitProperyExpression は、軽い引用符のプロパティ初期化子を NodeBuilderPropertyExpression のインスタンスにラップします。
Migrate_MergeNamedAndDefaultMenus は、変換の定義を上向きにし、メニューを新しい概念に置き換えます。変換メニュー（TM）と代替メニュー（SM）がリファクタリングされ、名前付きとデフォルトの概念バリアントがそれぞれ 1 つの概念（それぞれ TransformationMenu と SubstitutionMenu）にマージされました。デフォルトのバリアントと名前付きのバリアントの違いはまだありますが、個別のルートコンセプトではなく、各コンセプトの type プロパティによって処理されるようになりました。
4 つの移行はすべて再実行可能であるため、マージによって移行されていないコードがブランチに取り込まれた場合は、繰り返し実行できます。
VCS 設定を更新する
MPS マージドライバーが改善されます。競合するブランチをマージする前に、マージドライバーと VCS 設定が最新であることを確認してください。MPS の VCS サブシステムが正しく機能するには、Git が特定の方法で構成されている必要があります。プロジェクトの古い VCS 構成は、プロジェクトを開くときにユーザーに表示されます。VCS -> MPS VCS アドオンのインストールメニュー。
インストールが完了すると、VCS システムの準備が整います。
推奨される移行戦略
両方が別々に MPS 2020.1 に移行された 2 つのブランチをマージすると、頭痛の種になる可能性があります。避けてください ! そうでなければ、これはあなたの愛する人に起こります:
複数行にまたがるすべての単一行コメントは、単一行コメントの新しいインスタンスに分割されます。これは、各ブランチの異なるノードであり、競合します。
このステートメント内に追加の変更がある場合、両方のブランチの TryUniversalStatement の新しいインスタンスは競合します。
移行が NodeBuilderPropertyExpression ラッパーで強化する簡単な引用は、競合します。
すべての変換メニューと置換メニューは競合するため、どちらか一方を受け入れる必要があります（ルートノードの概念が変更され、メニューに新しい子ノードがあります）。これは、変換 / 置換メニューのルートノードが概念を変更し、実際には異なるインスタンスであるためです。1 つずつマージすることができ、ブランチでメニューが変更されなかった場合、1 つのブランチでメニューが変更された場合は、必要に応じて AcceptYours または AcceptTheirs 戦略を使用できます。
1 つのステップですべてのブランチを MPS 2020.1 に移行することを強くお勧めします。
推奨されるシナリオは次のとおりです。
すべてのブランチをマスターにマージします。
移行アシスタントを使用してマスターを移行します。
Migratetry ステートメント拡張スクリプトを実行します。
移行したマスターから新しいブランチを起動します。
「Migrate try ステートメント拡張スクリプトを実行する」ステップについては、少し説明が必要です。try ステートメントの通常の移行は防御的な方法で機能し、コードの破損につながる可能性がある状況での移行を回避します。これらは通常、ジェネレーターテンプレートフラグメント、マクロ、コメントアウトされたノード、引用符内の try ステートメントです。移行でスキップされるコードを手動で更新する必要を避けるために (移行されていないノードは移行によって報告されるため、そのリストが表示されます)、これらの複雑なケースの移行を試みるために、try ステートメントを移行すると呼ばれる拡張スクリプトが提供されています。ただし、コードが壊れる可能性があるため、結果を手動で検証する必要があります。
代替の移行戦略
それを手助けすることができず、移行されていないブランチを移行されたマスターにマージする必要がある場合は、次のセクションで説明するシナリオに従う必要があります。
マージの競合を解決する
再実行可能な移行を実行する
手動で差分を確認する
「Migrate try ステートメント」拡張スクリプトを実行します
手動で差分を確認する
コミット
これらのトピックについては、これから詳しく説明します。
マージの競合を解決する
editor.mps ファイルの競合 (jetbrains.mps.lang.editor)
SingleLineComment の競合 (jetbrains.mps.baseLanguage)
ブランチで変更されていない単一行コメントはマスターから取得されるため、すでに移行されています。これらは、適切なツールボタンを使用して自動解決できます。
残りの競合する変更は、おそらくブランチからの変更を受け入れる（受け入れる）ことによって、手動で移行する必要があります。移行されていない SingleLineComment のインスタンスは、コードに再挿入されます。
上記の図解コードの最後のコメントのように、複数行にまたがる単一行のコメントには特別な注意を払う必要があります。移行により、追加の行が SingleLineComment のスタンドアロンインスタンスに分離されたため、元の SingleLineComment インスタンスにぶら下がっています。また、ブランチからの変更をマージすると、 SingleLineComment の元の（一番上の）インスタンスの場合、以下の行はコメントのテキストを複製します。
重複する末尾の 1 行コメントは削除できます。ただし、一部の行には、メインブランチからのコメントのテキストへの変更が含まれる場合があります。これらは手動で単一行コメントにコピーする必要があり、その後でのみ末尾のコメントを削除できます。
このようにして、すべての競合を解決し、ダイアログを閉じます。ただし、コードには、ブランチからの SingleLineComment の移行されていないインスタンスが含まれています。
移行されていない TryCatchStatement/TryFinallyStatement とすでに移行されている TryUniversalStatement の間の競合 (jetbrains.mps.baseLanguage)
変更は移行された try ステートメント内にのみありました - これは最も単純なケースであり、競合は発生しないはずです。自動的に受け入れられなかった場合は、変更を受け入れるだけです。
変更は移行されていない try ステートメント内にのみありました - ここでは、移行されていないブランチからの変更を受け入れ、移行されたものからの変更を無視する必要があります（実際には、失う意味のある変更はなく、次で繰り返す移行のみです。ステップ、）。
変更は両方のブランチの try ステートメント内にありました - これは最も複雑なケースです。変更を受け入れるブランチ（移行されていないまたは移行された）の 1 つを選択します。移行されたブランチを使用することをお勧めしますが、ほとんどの変更が移行されていない場合もあります。その場合は、おそらくそれを選択する必要があります。次に、選択したブランチからの try ステートメントの変更を受け入れ、他のブランチからの try ステートメントの変更を無視します。最後に、他のブランチからの変更を手動でコピーして貼り付けます。3 方向マージダイアログで直接行うと便利です。右または左のエディターからステートメントをコピーして、中央のエディターに貼り付けます。
移行されていない見積もりと移行された軽い見積もりの間の競合
再実行可能な移行を実行する
マージ後のマスターには、移行されていないコードが含まれている可能性があるため、コードを MPS 2020.1 にアップグレードするには、移行を再実行する必要があります。メニューから「再実行可能な移行の実行」アクションを実行して、それを簡単に実行します。
手動で差分を確認する
上記の変更によってコードにエラーが発生しなかったことを手動で確認してください。
'Migratetry ステートメント ' 拡張スクリプトを実行する
通常の移行シナリオと同様に、try ステートメントを移行する拡張スクリプトを実行して、コードの破損を回避するために移行がスキップされた場合に自動的に移行を試みます。
手動で差分を再度確認してください
前の手順で一部のコードが破損した可能性があるため、変更を手動でインスペクションし、最終的に修正する必要があります。
コミット
これで完了です。これで、コードをコミットできます。
MPS 2019.2 への移行
構造体の列挙宣言の移行
MPS 2019.2 は、構造体列挙を宣言する新しい方法を備えています。既存の列挙宣言はこの機能によって非推奨になります。MPS は、新しい構造に置き換えるための一連の移行スクリプトとその使用箇所を提供します。この記事では、これらの移行がどのように処理されるかを正確に説明します。
列挙宣言のアップグレード
まず、移行により、古い列挙宣言が注目の宣言に置き換えられます。移行された言語の非推奨の列挙ごとに、移行は機能化された概念を使用して新しい列挙を作成します。また、移行では、古い列挙宣言が移行の特定の属性に配置され、この宣言が機能しなくなり、文書化と移行の補助としてのみ存在することを示します。
新しい宣言にはさまざまな種類のプロパティ（概念のプロパティではなく、一般的な意味）が含まれているため、古い宣言のプロパティを新しい宣言にマッピングすることは簡単ではない可能性があります。ここでは、移行が古い列挙宣言の各プロパティをどのように処理するかについて説明します。
古い列挙の名前は、新しい宣言の名前に簡単にコピーされます。
「デフォルトあり」と「デフォルトのメンバー」は単なる「デフォルトのメンバー」になりました。
「空のテキスト」、「メンバーデータ型」、および「メンバー識別子ポリシー」はサポートされなくなりました。
古い列挙のメンバーごとに、移行により新しい宣言にメンバーが作成されます。メンバーの「外部値」は「プレゼンテーション」になりました (つまり、新しい列挙宣言の 2 列目のオプションのテキスト行です)。メンバーの「内部値」と「識別子」はサポートされなくなりましたが、新しい列挙メンバーに適切な名前を選択するために使用されます。
列挙型プロパティのアップグレード
移行された列挙型宣言ごとに、移行により、古い列挙型のプロパティ宣言が新しい列挙型の新しいプロパティ宣言に置き換えられます。移行では、古いプロパティ宣言を移行の属性に配置して、使用箇所の移行を適切に処理します。
smodel およびアスペクト言語のコードの移行
MPS 2019.2 は、新しい構造の列挙を操作するための簡潔なエクスペリエンスを提供します。SModel 言語は、smodel クエリで生の値ではなく「enummember<_>」型を使用して新しい列挙のプロパティ値を提示します。生の値は古い列挙型メンバーには不可欠でしたが、smodel クエリで設計時のサポートが不足していたため、新しい列挙型では削除され、「enummember<_>」型に置き換えられました。新しいアプローチにより、言語設計者は、列挙型メンバーに対するエレガントなスイッチ操作を提供することで、プロパティアクセス操作の型をより制限し、ボイラープレートを削減して正しいコードを作成できるようになります。ただし、このアプローチは、言語設計者が列挙型メンバーの「生の値」を使用する必要があった古い列挙型の smodel コード動作とは互換性がありません。新しい列挙型で動作するように smodel クエリを更新するには、追加の移行が必要です。
smodel およびアスペクトコードの移行は、コードが構造アスペクトの移行によって新しい代替に置き換えられた列挙プロパティまたは列挙宣言を参照するときにトリガーされます。基本的に、そのような参照ごとに、これらの移行の 1 つが、新しい版を参照するように更新します。移行では、コードのセマンティクスを維持するために近くのコードも調整されます。このような手順でコードが大幅に変更される場合があるため、以下で詳しく説明します。
列挙型プロパティに対するノードのプロパティアクセス操作は、これらの式の入力規則が古い列挙型と新しい列挙型で異なるため、移行によってコードが大幅に変更される状況の 1 つを表しています。smodel コードを処理するときに移行が従う一般的なルールがあります。
列挙宣言に「ブール」メンバーデータ型があった場合、smodel コードセマンティクスは列挙メンバーの「is」チェックを使用して復元されます。
列挙型宣言に「整数」メンバーデータ型があり、そのメンバーが 0 または 1 から始まる順序付けされた序数シーケンスを形成している場合、移行により列挙型のメンバーリストに対して "indexOf" 操作が生成されます。
列挙型宣言のメンバーデータ型が「文字列」の場合、新しいメンバー宣言に指定された名前 / プレゼンテーションが過去の内部値と一致する場合、移行により列挙型メンバーに対して「名前」または「プレゼンテーション」操作が生成される可能性があります。通常、内部値が名前付けの制約を満たしておらず、メンバーのプレゼンテーションと一致しない場合を除き、これが当てはまります。
それ以外の場合、移行により、初期 smodel コードのセマンティクスをエミュレートする特別なメソッドへの呼び出しが生成されます。移行スクリプトは、列挙型所有言語内の「enumMigration」と呼ばれる別個のモデルに、そのようなメソッドを事前に作成します。
移行スクリプトは、一部の列挙型プロパティへのアップグレードが原因で型の不一致が発生する可能性があるすべての場所に同様の変換を適用します。そのような場所のリストは次のとおりです。
ノードのプロパティの読み取りおよび書き込みアクセス
ジェネレーターのプロパティマクロクエリ
プロパティ制約のクエリ
トランザクションプロパティセルに対するエディターのクエリ
ノードビルダーのプロパティ初期化子 (別名 . 軽い引用)
ノード引用符でのプロパティの引用符解除
ノードパターンでのプロパティパターン変数の使用
元のセマンティクスを維持するために移行でコードを大幅に変更する必要があるもう 1 つの場所は、列挙型メンバーに対する古い「名前」と「値」の操作です。移行では、そのような場所は上記と同様の方法で処理されます。
変換が使用される可能性のある場所が潜在的に多数あるため、移行スクリプトは、そのような変換が不要なコード内のパターンも検出するか、ユーザーコードベースへの変更を少なくするために簡略化できます。
手動移行
MPS は新しい列挙型の自動移行を提供しますが、ユーザーは自分のコードを手動で移行することになる可能性があります。例: これは、マージの競合の解決中に発生する可能性があります。ここでは、手動移行の一般的なシナリオについて説明します。
MPS がすでに移行を実行している言語で、移行されていない列挙型または移行されていない列挙型プロパティに遭遇した場合は、移行 -> 移行 -> 再実行可能な移行の実行を使用して移行スクリプトを再実行することを検討してください。
移行されていない smodel コードも、このアクションで処理できます。ただし、smodel コード内のプロパティ、列挙型、そのメンバーの参照を古い宣言から新しい宣言に置き換えることで、smodel コードを手動で更新することもできます。その後、型エラーが発生する可能性があるため、手動でも解決する必要があります。
場合によっては、smodel コードがプロパティを直接参照するのではなく、プロパティ属性を介して間接的にプロパティに依存することがあります。プロパティ属性を手動で移行するには、属性に対して「手動で移行」インテンションを呼び出し、その後、考えられる型エラーを修正する必要があります。
コードのクリーンアップ
列挙型移行では、移行プロセス中に多くの追加属性が生成されます。移行フレームワークでは、依存するモジュールやプロジェクトに応じてさらに移行を正しく処理するために、このような属性が必要です。ただし、言語設計者は、プロジェクトの外部にそのような依存モジュールがあることを期待していない可能性があるため、移行属性を削除したいと考えています。この章では、それを行う方法と、それが安全な変更である状況について説明します。
移行プロセスによって生成されるアーティファクトには、新しい列挙型の移行属性、列挙型プロパティの移行属性、「enumMigration」モデルの補助メソッドの 3 種類があります。
移行された列挙の属性は、特定の列挙を参照する smodel コードと、所有言語で記述されたモデル内のプロパティインスタンスを正しく移行するためのデータを提供します。一般に、このような列挙型を所有する言語が外部に公開されている場合、移行を正しく実行するには移行属性を保持する必要があることを意味します。ただし、サンドボックス / テスト言語、内部プロジェクトの言語には当てはまりません。これらのシナリオでは、言語設計者は、移行された列挙型に対して " 列挙型移行の属性を削除 " インテンションを呼び出して、列挙型の移行属性を正当に削除したい場合があります。
移行された列挙プロパティの属性は、依存する smodel コードを処理する場合にのみ必要です。つまり、言語設計者が、自分の言語を拡張したり、列挙プロパティで動作する smodel コードを維持したりすることを想定していない場合は、そのような属性を安全に削除できます。これを行うには、「列挙プロパティ移行の属性の削除」を呼び出すことを検討してください。
同様に、「enumMigration」モデルの補助メソッドは、smodel コードを移行する場合にのみ必要です。設計者がプロジェクト外の移行された列挙のメンバーで動作する smodel コードを予期しておらず、プロジェクト内に出現箇所がない場合は、そのようなメソッドを手動で削除する可能性があります。
属性の削除は選択次第であることに注意してください。たとえば、MPS チームは、いくつかのリリース後に自動コードクリーンアップを実行するようにスケジュールします。
メタ言語の自動移行の実装
この章は主に、新しい側面を実装するか、既存の側面を拡張する MPS 拡張機能のライター（エディターなど）を対象としています。ここでは、MPS メタ言語の変更を調整するために拡張機能を更新する方法について説明します。
この章では、列挙データ型を移行するための MPS メタ言語 API について説明します。便利なユーティリティメソッドまたは移行の例を参照する MPS ソースコードへのリンクが多数含まれています。MPS 2019.2 アプリケーションを開いて、これらのリンクを移動できるようにします。
一般的に、一部の MPS 拡張機能が、プロパティ宣言またはデータ型宣言を参照する、他の手段でそれらに依存する概念を提供する場合、この概念の設計者は、概念のインスタンスを更新するための移行を提供する必要があります。そうしないと、MPS 列挙型移行を適用した後、この概念のノードが古いコードに依存するようになるため、ユーザーはそれらを手動で修正する必要があります。移行はコンセプトごとに異なる可能性があるため、MPS はすべての可能な拡張機能に対して一般的なソリューションを提供することはできません。代わりに、MPS は、拡張機能の作成者が移行を効率的に実装するのに役立つ一連のユーティリティ関数を提供します。以下に、考えられるいくつかの一般的なシナリオについて説明します。
概念のプロパティ宣言に参照リンクがある場合:
ここでの標準的な例は、エディターセルプロパティの移行です。
概念にデータ型宣言への参照リンクがある場合:
「enummember <_>」インスタンスの移行は、「migrateEnumReference」の使用例です。
概念に列挙型のメンバー宣言への参照リンクがある場合:
列挙型プロパティに対する非推奨の「is」操作の移行は、例として役立ちます。
BL 式またはクエリの型指定規則がデータ型に依存する場合:
説明した最初の 2 つのシナリオのように、一部の概念が古い列挙型から新しい列挙型に移行され、プロパティ値の BL 型で操作する入力規則がある場合、この概念のノードでは、これが発生した場合でも型エラーが発生する可能性があります。移行前のノードは正しかった。
「smodel とアスペクト言語のコードの移行」セクションで説明されている「WeekDays」列挙の smodel コードの移行の例に戻りましょう。smodel の移行により、プロパティアクセス操作でプロパティ参照が更新されると、そのような操作の BL 型が突然 `string` から ` enummember <WeekDays> ` に変更されるため、smodel の移行では、このプロパティの読み取りが ` name の呼び出しでさらにラップされます。` 列挙メンバーから生の値を抽出して、式全体が移行が適用される前と同じように動作するようにする操作。smodel 移行スクリプトは、実際にはそのような呼び出しの作成を実装しませんが、代わりに補助クラス `jetbrains.mps.lang.smodel.migration.EnumExpressionsMigration` に委譲します。このクラスは、言語設計者が自分の拡張機能で同様の問題を通過するために使用できる一連のメソッドを提供します。
特に、いくつかの方法を提供します。
`downgradeExpressionType（node <EnumerationDeclaration> enumeration、node <Expression> expression）`-`enummember <$enumeration$>` 型の指定された $expression$ を変換して、最初に評価された列挙メンバーの生の値に評価します。
`upgradeExpressionType（node <EnumerationDeclaration> enumeration、node <Expression> expression）` -$enumeration$ の古い宣言を使用して、生の値に評価される特定の $expression$ を変換し、そのような生の値を表す実際の列挙メンバーに評価します。
`upgradeQueryReturnExpressions（node <EnumerationDeclaration> enumeration、node <IMethodLike> query）` -$enumeration$ の古い宣言を使用して、生の値に評価される特定の $query$ 本体を変換し、そのような生の値を表す実際の列挙メンバーに評価します。技術的には、クエリのすべての return 句を収集し、`upgradeExpressionType` 機能で変換します。
` optimize() `- この ` EnumExpressionsMigration` インスタンスで変換された式の周囲のコードを最適化しようとします。`EnumExpressionsMigration` を使用した一般的なワークフローは、次の手順に従います。移行スクリプトの開始時にインスタンス化され、上記の 3 つのメソッドを使用してユーザーモデルを修正し、` optimize()` メソッドを呼び出して変換されたコードをクリーンアップします。
例: プロパティ制約の移行スクリプトは、EnumExpressionsMigration ユーティリティの使用箇所を強調しています。
概念が PropertyAttribute を拡張する場合:
コンセプトが `PropertyAttribute` を拡張する場合、そのようなコンセプトの属性を更新する移行が必要です。移行スクリプトは、`EnumUsagesMigration#migrateEnumPropertyAttribute（node <PropertyAttribute>）` を呼び出して更新する必要があります。属性が列挙型のプロパティ用であり、属性がまだ移行されていない場合、メソッドは新しい列挙型プロパティ宣言を返します。それ以外の場合、メソッドは null を返します。
ジェネレーターのプロパティマクロは、「PropertyAttribute#getPropertyDeclaration」の使用箇所とプロパティ属性の移行の良い例です。
