5

バックグラウンド

私はVrapperプロジェクトの開発者です。

Vrapper には 2 つの主要なパーツが含まれています

  • Vim エミュレーション ライブラリ (vrapper.core)
  • それを活かしたエクリプスパーツ

vrapper.core を Eclipse 非対応にしたいので、Eclipse の外で再利用できます。現在、あらゆる種類の Eclipse テキスト エディターと、単体テストに使用する小さなモック テキスト エディターを "vrap" できます。

vrapper.core は、あらゆる種類の Vim コマンド、モードなどを実装します。これらはすべてプラットフォーム (テキスト エディター、クリップボード、設定システムなど) を抽象化するインターフェイスであるプラットフォームと通信します。

エディター用にモードが作成されると、基になるエディター、現在編集されているファイルの種類などに適した追加のコマンドがあるかどうかをプラットフォームに尋ねます。

EclipsePlatform は、Eclipse 拡張ポイント メカニズムを使用してこれらのコマンドを提供します。

それでは、次のプロジェクトを考えてみましょう (他にもあります)。

  • vrapper.core - Vrapper の Eclipse に依存しないコード
  • vrapper.eclipse - vrapper.coreに依存する Eclipse プラグイン
  • Surround.core - Surround.vim (Vim プラグイン)をエミュレートする Eclipse に依存しないコード
  • Surround.eclipse - Surround.core からコマンドを提供するvrapper.eclipseの Eclipse フラグメント。

これらに対処するには、次の 2 つの方法があります。

1 つのプラグインですべてを支配

これは、Eclipse の観点からどのように見えるかです。vrapper.eclipseおよびvrapper.coreからのコードを含む 1 つのプラグインと、Surround.coreおよびSurround.eclipseからのコードを含む 1 つのフラグメントがあります。

多くのプラグイン

  • 3つのプラグインがあります
    • 2 つの OSGified ライブラリvrapper.coreSurround.core
    • vrapper.eclipse
  • この場合、 Surround.Eclipse フラグメントは vrapper.core に依存ます

問題

多くのプラグイン ソリューションには、遅延クラスの読み込みに関する問題がいくつかありますが、これは私には理解できません。これは、vrapper.coreからモードのインスタンスが作成されるときに、( vrapper.eclipse -> Surround.eclipseを介して) Surround.coreからクラスを作成する必要があるためです。

これは、Eclipse から何かを実行し、実行構成からすべてのプラグインを選択する場合に機能しますが、機能とプラグインをデプロイして Eclipse を正常に実行すると、sround.core のクラスが見つからないため、例外がスローされます。これは、依存するプラグインから追加のコマンドを要求する Surround.coreの精神に基づくものであり、暗黙的な循環依存関係が作成されます。

暗黙の依存関係とは、コンパイル時にコア クラスが Eclipse 固有のクラスに依存しないことを意味します。

モード (vim ノーマル モードなど) はコア クラスです。コマンドが含まれています。特定の Eclipse エディターに固有のコマンドがいくつかあります (この JDT 固有のリファクタリングを実行するなど)。これらのコマンドはコア インターフェイスを実装しますが、それらのコードは (明らかに) Eclipse 固有のプロジェクトに存在します。モードが作成されると、基礎となるプラットフォームにいくつかの追加コマンドを要求します。これらの追加コマンドは、Eclipse プラグインに実装されます。これは、Eclipse での遅延クラス読み込みが実行時にすべてを爆発させるときです。追加のコマンドのクラスは拡張ポイントによって参照されますが、まだ読み込まれていません。ブーム、例外。

「1 つのプラグインですべてを支配する」アプローチを使用して、この問題を回避しようとしました。プラグインを 1 つだけ使用する方がはるかに優れているように思えますが、きれいに動作させることはできませんでした。

私にとって成功したのは、かなり醜いハックだけでした。

  • すべての.coreプロジェクトには、クラスを含む .jar ファイルを作成し、それを対応する*.eclipseプロジェクトにドロップする Ant タスクがありました
  • *.eclipseプロジェクトにはその jar が含まれており、MANIFEST ファイルに登録されていました。

この醜いハック アプローチの問題点は (醜いハックであることに加えて)、開発が非常に苦痛になることです。Eclipse のコード ナビゲーション、コード カバレッジ、および Eclipse の他のいくつかの機能が機能しなくなります。

概要

Eclipseに依存しないライブラリ + Eclipse 固有のもののアーキテクチャがありますが、これらすべてを 1 つのプラグインに組み込む必要があります (双方向にいくつかの依存関係があるため)。

いくつかのプロジェクトのコードを 1 つのプラグイン/フラグメントにライブ化するにはどうすればよいですか?

4

2 に答える 2

4

Eclipse-BuddyPolicy:dependentを MANIFEST.MF ファイルに追加し、いくつかの依存関係を再エクスポートし、1 つのフラグメントをプラグインに変換する (したがって、追跡する BuddyPolicy のプラグイン依存関係がある) ことが正しい解決策であることが判明しました。

問題が解決しました :-)

于 2009-11-21T04:34:01.490 に答える
0

これを読むと、実際の問題は両方向に依存関係があるという事実にあるように思えます。プロジェクトをリファクタリングして、Eclipse 固有のプロジェクトのみがコア プロジェクトに依存するようにし、その逆を行わないようにすることはできませんか?

于 2009-11-20T21:32:04.563 に答える