-Eclipseプラグインとコンテナ

Eclipseプラグインを作るのが大変なのは、ドキュメントが無いとかいうのを別にすると、テストがしにくいということです。ログも取るの大変ですし、例外処理がめんどくさい。また、Plugin設定ファイルのExtensionPointへの設定は、初期化がしにくいのです。デフォルトコンストラクタ一発で組み込んでしまうので、Dependency Injectionなつくりにできません。
そこで、ふとひらめきました。プラグインの内部にIoCコンテナを使ってもいいんだなと。Eclipseに要求されるExtensionPointのインターフェイスやクラス型のところを極力薄いラッパーにして、中の操作はすべてPOJOで作ることも可能かを考えてみました。これができるとして、このPOJOをプラグインに組み込んだコンテナから取得する実装にします。コンポーネントなら、コンテナ設定でテスト時にAspect使ってメソッドにどういう値がわたってきているか細かくログを出したりすることも可能です。どうせプラグインの例外処理はCoreExceptionに例外をラップしてエラービューに出すだけですから例外処理は横断的にできます。バージョン管理もコンポーネント単位で行っていけば後の機能追加が柔軟にできます。設定XMLのバリデーションに例をとると、BuilderをつくるとかNatureがという話がいきつくところ、結局最終的にはSAXプログラミングの世界になります。エラーハンドラでプラグインのラッパーと通信すればOK（だと思う）。よって、まずは設定XMLをパースして問題が生じたらエラーハンドラを発火するPOJOをきちんと作ることが大事なのです。それなら、Eclipseプラグインの外でつくれます。ということで、まず欲しい機能をPOJOで作るということをオススメ。Editorは、パーサーと、カラーディクショナリと、入力候補ディクショナリというように、結構たくさんのパーツで作ることになるのかな？と思います。
Eclipseプラットホームも一種、変わった形のコンテナです。Extensionがコンポーネントで（S2プラグインとかSpindleとか言うときの、広い意味でのプラグイン。狭い意味ではExtensionの一種としてPluginとかEditorとかActionがある）、ルックアップのIDがExtensionID。コンポーネントをぶち込む他のExtension（Eclipse自体がExtensionの集合体）のSetterみたいなものがExtensionPointです。