私は現在、静的コード アナライザー用の Eclipse プラグインに取り組んでいます。アナライザーは Java で書かれています。これまで、Eclipse プラグインは独自の起動構成タイプと のサブクラスをJavaLaunchDelegate
使用して、別のプロセスでコード アナライザーを実行していました。Eclipse プラグインとコード アナライザーは、新しいプロセスの stdin と stdout を介して通信しました。それはかなり醜いものでした:-P
では、これをきれいにすることを目指します。まず、コード アナライザーを jar ファイルだけでなく、Eclipse プラグインにも変換しました。次に、stdio ベースの通信を適切な Java インターフェイスに置き換えました。コード アナライザーは、Eclipse プラグインに API を提供します。これはすべてうまくいきます。
ただし、Eclipse プラグインは、独自の起動構成タイプとそのサブクラスを引き続き使用してJavaLaunchDelegate
、分析を実行します。つまり、コード アナライザー自体が Eclipse プラグインになっているため、分析は同じプロセスで行われます。ただし、Eclipse プラグインは、コード アナライザーを使用せずに追加のプロセスを起動します。
質問
古いセットアップからまだ何が必要ですか?
JavaLaunchDelegate
を単純な に変換できると確信していLaunchConfigurationDelegate
ます。これにより、Eclipse プラグインが無用なプロセスを起動するのを防ぐことができます。
次に、 で、plugin.xml
独自の起動構成タイプを次のように宣言します。
<extension
point="org.eclipse.debug.core.launchConfigurationTypes">
<launchConfigurationType
delegate="com.example.LaunchDelegate"
id="com.example.launch.config"
modes="run,debug"
name="Launch"
sourceLocatorId="org.eclipse.jdt.launching.sourceLocator.JavaSourceLookupDirector"
sourcePathComputerId="org.eclipse.jdt.launching.sourceLookup.javaSourcePathComputer">
</launchConfigurationType>
</extension>
sourceLocatorId
ここで、 and属性を削除できるかどうかはわかりませんsourcePathComputerId
。起動構成は引き続き Java コードを起動しますが、別のプロセスで起動することはなくなりました。ではない起動デリゲートでこれらの属性を使用する場合、これらの属性は意味がありJavaLaunchDelegate
ますか?
最後に、起動構成を引き続き使用することが良い考えであるかどうかはまったくわかりません。これは、実際には追加のプロセスを起動するのではなく、Eclipse プロセスで実行される操作であるためです。このユースケースに起動構成を使用することは適切ですか? また、現在、 のサブクラスを使用してAbstractLaunchConfigurationTabGroup
、分析のパラメーターを構成しています。Eclipse プロセスで操作を起動し、GUI を介してこの操作のパラメーターを提供できる独自の起動構成タイプに代わるものはありますか?
質問のまとめ
JavaLaunchDelegate
を単純なものに置き換えることはできますLaunchConfigurationDelegate
か?sourceLocatorId
およびsourcePathComputerId
属性を独自の起動構成タイプの宣言から削除できますか?- 起動構成を使用して、Eclipse プロセスで実行される静的コード分析を実行することは適切ですか?
- そうでない場合、Eclipse プロセスで操作を起動し、GUI を介してこの操作のパラメーターを提供できる独自の起動構成タイプに代わるものはありますか?