![[PukiWiki]](https://www.masatom.in/pukiwiki/image/kinosite.png "[PukiWiki]"){kind=small}
Eclipseのプラグインですが、3.1からjar化されて配布される形式が導入されました。よく見てみると、プラグイン内の構成も変更されています。例えば
このように新構成の形式にすることで、プラグインのjarは単純なjarファイルとなり、Eclipse以外の環境でもそのままパスを通して使用できるようになりました。つまりEclipse上ではEclipseプラグインなんだけれども、他の環境、例えばWEBコンテナ上ではWEB-INF/libに置くことのできるjarファイルである、というような構成にすることができるわけです。例えばインタフェースだけを格納した新構成のプラグインjarを作成し、サーバでもクライアントでもそのjarを使ってインタフェースを共通に保つ、なんて芸当ができますね。すばらしい。。
さて、その新構成のプラグインの作り方ですが基本的に、プラグインプロジェクトを作成するときにターゲットバージョンを3.1にして、OSGiバンドル・マニフェストを作成、を選択することが必要みたいです。基本的にそれでＯＫなんだけど他にもちょっと条件があるみたい。条件、というか制約があるって言うか。。
忘れないうちにメモしておきます。
<plugin id="org.eclipse.core.resources.win32" unpack="false"/>などと unpack="true|false" で制御できます。指定しない場合はtrueなので、書かないと解凍しちゃうわけですが、feature.xmlを作るとデフォルトでunpack="false"と書いてあります。ややこしい。マニフェストエディタでは「インストール後にプラグイン・アーカイブを解凍します。」というのにチェックを入れないと、unack="false"となります。
上のバグって言ってたヤツ、Eclipse.3.2.xあたりから直ってるみたい。ようするにjarを追加すると、勝手に「.(ドット)」が追加されました。、、んー、昔からこうだったのかな？？？
さてこの「.(ドット)」って何なのかなと思ってたのですが、ある人に教えてもらいました。これはソースディレクトリ内のソースコードからビルドされたクラスファイルを、プラグイン直下に配置しなさい、という意味になってます。
例えば、ここにドットを追加すると、MANIFEST.MFには
Bundle-ClassPath: lib/log4j-1.2.13.jar, . <-これ
が追加され、build.propertiesには
source.. = source/
が追加されます。さらに、ここに nu.mine.kino.plugin.log4j.jar を追加するとMANIFEST.MFには
Bundle-ClassPath: lib/log4j-1.2.13.jar, nu.mine.kino.plugin.log4j.jar <-これ
が追加され、build.propertiesには
source.nu.mine.kino.plugin.log4j.jar = source/
が追加されます。んでこの意味はsource内のクラスファイルはjarにして(ファイル名はnu.mine.kino.plugin.log4j.jar)プラグイン直下に置け、ということのようです。これをふまえると
source.. = source/
の意味はsource内のクラスファイルはそのままでプラグイン直下に置け、という意味になり、上で述べてたようなクラスファイルが裸で配置されて気持ち悪いという状態になります。
よってココにjar名を書いておいてbuild.propertiesでディレクトリとの紐付けを行っておけば*2、unpackするプラグインもクラスファイルを裸で置かないで済むわけです。いやあ、これが正しいですね。
よってドットを追加するのではなく、プラグイン内のクラスファイルをアーカイブするjar名を追加しておく、というのが正しい対応だと言うことがわかりました。
この記事は
現在のアクセス:12331
