// 下階層用テンプレート
#topicpath
----
//ここにコンテンツを記述します。

***Eclipse3.1から新構成のプラグインになりました。 [#y7821863]
Eclipseのプラグインですが、3.1からjar化されて配布される形式が導入されました。よく見てみると、プラグイン内の構成も変更されています。例えば
-トラディショナルなプラグインは、プラグイン自身のディレクトリのなかに、クラスをパックしたjarファイルをもつ
-新構成のプラグインは、プラグイン自身がjarファイルとなり、直接その中にクラスファイルをもつ

このように新構成の形式にすることで、プラグインのjarは単純なjarファイルとなり、Eclipse以外の環境でもそのままパスを通して使用できるようになりました。つまりEclipse上ではEclipseプラグインなんだけれども、他の環境、例えばWEBコンテナ上ではWEB-INF/libに置くことのできるjarファイルである、というような構成にすることができるわけです。例えばインタフェースだけを格納した新構成のプラグインjarを作成し、サーバでもクライアントでもそのjarを使ってインタフェースを共通に保つ、なんて芸当ができますね。すばらしい。。

***作り方 [#w0061448]
さて、その新構成のプラグインの作り方ですが基本的に、プラグインプロジェクトを作成するときにターゲットバージョンを3.1にして、OSGiバンドル・マニフェストを作成、を選択することが必要みたいです。基本的にそれでＯＫなんだけど他にもちょっと条件があるみたい。条件、というか制約があるって言うか。。

忘れないうちにメモしておきます。
-プラグインのエクスポートウィザードなどでエクスポートすると、基本的にjar化した新構成プラグインを作ろうとするんだけど、featureをつくる場合はfeature.xmlでunpackするかどうかを制御できます。例えば、プラグインのなかに設定ファイルなどを置く場合、jarファイル化されるとファイルにアクセスできなくなっちゃうので((ファイルとして存在してくれないと困る))、その場合はfeature.xmlでunpackの指定で明示的に解凍することができます。でもこの場合、ホントにjarを解凍しちゃうので、プラグイン自身のディレクトリを開いてみると*.classファイルが見えちゃうわけです。なんかかっこわるいですね。。。ちなみにunpackの指定方法は
 <plugin id="org.eclipse.core.resources.win32" unpack="false"/>
などと unpack="true|false" で制御できます。指定しない場合はtrueなので、書かないと解凍しちゃうわけですが、feature.xmlを作るとデフォルトでunpack="false"と書いてあります。ややこしい。マニフェストエディタでは「インストール後にプラグイン・アーカイブを解凍します。」というのにチェックを入れないと、unack="false"となります。
-あるプラグインＡで、そのプラグインＡ内に(例えば誰か作った)jarを置いてそこにパスを通すような場合、*.productファイルのエクスポートウィザードなどでプラグインをExportすると、自動的にunpackされるみたいです。すでにjarを内包してるので、デフォルトで解凍してくれるのかな。
-このようにプラグインＡ内でjarにパスを通した場合、注意しなくてはいけないのが、自分が作ったクラスファイルがデフォルトではプラグイン内に取り込まれない、と言うことです。プラグイン内でjarにパスを通すのって、マニフェストエディタの「ランタイム」タブのクラスパスで行うのですが、そこに
#ref(pic.png)
と言うように「.(ドット)」にパスを通さないといけないみたい。タチが悪いのが、Eclipseのワークベンチ内でテストしてる分にはこの現象は発覚しないんだけど、エクスポートして初めて取り込まれないことがわかるようになっていて、ここで相当悩みました。ていうかバグじゃないこれ？？


***20070521追記。 [#k6a3b1ca]
上のバグって言ってたヤツ、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でディレクトリとの紐付けを行っておけば((これは勝手にやってくれる))、unpackするプラグインもクラスファイルを裸で置かないで済むわけです。いやあ、これが正しいですね。


よってドットを追加するのではなく、プラグイン内のクラスファイルをアーカイブするjar名を追加しておく、というのが正しい対応だと言うことがわかりました。




----
この記事は
#vote(おもしろかった,そうでもない)
-助かりました。この記事で「ドットを通さないといけない」というのを見つけるまで半日使ってしまいました。Eclipseプロダクト(exeから実行)ならＯＫになったのですが、WebRCPを使ってJWS形式で配布しようとすると依存ライブラリが見えてないみたいで、例外が発生してしまいました。。また悩みそうです。。 -- [[ねいのーさん]] &new{2006-07-26 21:28:40 (水)};
-わたしも半日は使いました(´д`;)。。エクスポートした場合と結構挙動がちがうんですよね。。。 -- [[きの]] &new{2006-07-26 21:41:37 (水)};
-JWSで配布で例外が発生した問題解決いたしました。WebRCPでテストする際、JNLPファイル記述するバージョン番号を変更せずテストしていた為、WebRCPが持っているアプリケーションディレクトリ(user.home/Local Settings/Temp/WebRCP-xxxxx)に、(jarが足りずに)動かないアプリが残ったままになっていました。バージョン番号書き換えたら正しく実行できました。お騒がせ致しました。m(_ _)m -- [[ねいのーさん]] &new{2006-07-27 10:59:23 (木)};
- Eclipse.3.2.xから上のドット問題は解消されてるみたい。いつの間にか、直ってましたね。 -- [[きの]] &new{2007-05-21 (月) 14:18:18};

#comment
#topicpath


SIZE(10){現在のアクセス:&counter;}
トップ   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS