「Eclipse プラグインパッケージガイドライン」の版間の差分
(トラブルシューティングを翻訳して追加) |
(他言語へのリンクを追加) |
||
1行目: | 1行目: | ||
[[Category:パッケージ開発]] |
[[Category:パッケージ開発]] |
||
[[en:Eclipse plugin package guidelines]] |
[[en:Eclipse plugin package guidelines]] |
||
− | [[ |
+ | [[es:Eclipse plugin package guidelines]] |
+ | [[pt:Eclipse plugin package guidelines]] |
||
[[zh-hans:Eclipse plugin package guidelines]] |
[[zh-hans:Eclipse plugin package guidelines]] |
||
{{Package Guidelines}} |
{{Package Guidelines}} |
||
8行目: | 9行目: | ||
== Eclipse プラグインの構造とインストール == |
== Eclipse プラグインの構造とインストール == |
||
+ | |||
基本的に Eclipse プラグインには2つのディレクトリが存在します: {{ic|features}} と {{ic|plugins}}。Eclipse 3.3 からプラグインが置ける場所は {{ic|/usr/lib/eclipse/}} と決まっていました。しかし、この2つのディレクトリの中身が他のプラグインの中身と混ざってしまうことがあり、そうなるともう手がつけられなくなって構造の管理が難しくなります。どのパッケージにどのファイルが含まれているのか確認するのは非常に困難だったと言わざるをえません。 |
基本的に Eclipse プラグインには2つのディレクトリが存在します: {{ic|features}} と {{ic|plugins}}。Eclipse 3.3 からプラグインが置ける場所は {{ic|/usr/lib/eclipse/}} と決まっていました。しかし、この2つのディレクトリの中身が他のプラグインの中身と混ざってしまうことがあり、そうなるともう手がつけられなくなって構造の管理が難しくなります。どのパッケージにどのファイルが含まれているのか確認するのは非常に困難だったと言わざるをえません。 |
||
2023年6月29日 (木) 21:06時点における版
32ビット – CLR – クロス – Eclipse – Electron – Free Pascal – GNOME – Go – Haskell – Java – KDE – カーネル – Lisp – MinGW – Node.js – ノンフリー – OCaml – Perl – PHP – Python – R – Ruby – Rust – VCS – ウェブ – Wine
Eclipse プラグインをインストールする方法は多数存在します。特に Eclipse 3.4 で dropins ディレクトリが導入されてから方法は増えました。しかしながら、中には汚いインストール方法もあるので、システムの構造を綺麗に保つためにパッケージングには標準的で首尾一貫した方法が必要です。Eclipse プラグインがどうやって動作するのか詳しい知識がないパッケージ作成者にとっては容易なことではありません。このページでは Eclipse プラグインの PKGBUILD の標準的でシンプルな構造を定義することで、ファイルシステムの構造を壊さないようにしつつ、パッケージを作成するときに毎回初めからやりなおさなくてもいいようにすることを目指しています。
目次
Eclipse プラグインの構造とインストール
基本的に Eclipse プラグインには2つのディレクトリが存在します: features
と plugins
。Eclipse 3.3 からプラグインが置ける場所は /usr/lib/eclipse/
と決まっていました。しかし、この2つのディレクトリの中身が他のプラグインの中身と混ざってしまうことがあり、そうなるともう手がつけられなくなって構造の管理が難しくなります。どのパッケージにどのファイルが含まれているのか確認するのは非常に困難だったと言わざるをえません。
上記のインストール方法は Eclipse 3.4 ではまだサポートされていますが、現在推奨されている方法では /usr/lib/eclipse/dropins/
ディレクトリを使います。このディレクトリの中にはサブディレクトリをいくらでも作成することができ、各ディレクトリに features
と plugins
サブディレクトリが存在します。構造を小さく綺麗にまとめることができるので、新しい方法を標準的なパッケージング方法とするべきです。
パッケージング
サンプル PKGBUILD
以下がサンプルです。カスタマイズする方法を下で詳しく説明します。
PKGBUILD-eclipse.proto
pkgname=eclipse-mylyn pkgver=3.0.3 pkgrel=1 pkgdesc="A task-focused interface for Eclipse" arch=('any') url="https://eclipse.org/mylyn/" license=('EPL') depends=('eclipse') optdepends=('bugzilla: ticketing support') source=(https://download.eclipse.org/tools/mylyn/update/mylyn-${pkgver}-e3.4.zip) sha512sums=('aa6289046df4c254567010b30706cc9cb0a1355e9634adcb2052127030d2640f399caf20fce10e8b4fab5885da29057ab9117af42472bcc1645dcf9881f84236') prepare() { # remove features and plug-ins containing sources rm -f features/*.source_* rm -f plugins/*.source_* # remove gz files rm -f plugins/*.pack.gz } package() { _dest="${pkgdir}/usr/lib/eclipse/dropins/${pkgname/eclipse-}/eclipse" # Features find features -type f | while read -r _feature ; do if [[ "${_feature}" =~ (.*\.jar$) ]] ; then install -dm755 "${_dest}/${_feature%*.jar}" cd "${_dest}/${_feature/.jar}" # extract features (otherwise they are not visible in about dialog) jar xf "${srcdir}/${_feature}" || return 1 else install -Dm644 "${_feature}" "${_dest}/${_feature}" fi done # Plugins find plugins -type f | while read -r _plugin ; do install -Dm644 "${_plugin}" "${_dest}/${_plugin}" done }
ビルドをカスタマイズする方法
カスタマイズする必要があるメインの変数は pkgname
です。普通のプラグインをパッケージ化するときは、pkgname
を変更するだけでパッケージが作れます。ほとんどのプラグインは zip ファイルで配布されていて features
と plugins
サブディレクトリだけを含んでいます。例えば、foo
プラグインをパッケージする場合、ソースファイルに features
と plugins
しか含まれていなければ、pkgname
を eclipse-foo
に変更するだけで準備が整います。
PKGBUILD の内部で何をやっているかは以下を読み進めてください。様々なパッケージでビルドをセットアップする方法を理解するのに役立つはずです。
PKGBUILD の解説
パッケージの命名
Eclipse 関連のパッケージとわかるようにパッケージの名前は eclipse-pluginname
としてください。不必要な ${_realname}
変数を使うことなく、${pkgname/eclipse-}
などの簡単なシェルの置換でプラグインの名前を簡単に抽出できます。インストール時のあらゆることをまとめて、衝突を避けるために、プラグインの名前は必須です。
ファイル
抽出
プラグインによっては jar ファイルからの抽出が必要です。JRE に含まれている jar
ユーティリティを使って抽出を行います。ただし、jar
はカレントディレクトリ以外のディレクトリに抽出ができないので、ディレクトリを作成して、ディレクトリに cd
してから抽出してください。${_dest}
変数を使うことで PKGBUILD の可読性を上げることができます。
場所
先に述べたように、ソースアーカイブには2つのディレクトリ features
と plugins
が存在しますが、それぞれに jar ファイルが詰め込まれています。dropins の推奨される構造は以下のようになります:
/usr/lib/eclipse/dropins/pluginname/eclipse/features/feature1/... /usr/lib/eclipse/dropins/pluginname/eclipse/features/feature2/... /usr/lib/eclipse/dropins/pluginname/eclipse/plugins/plugin1.jar /usr/lib/eclipse/dropins/pluginname/eclipse/plugins/plugin2.jar
上記のような構造にすることで、どのパッケージに何が入っているのかを明確にしながら、様々なプラグインが必要とする様々なバージョンのライブラリを混ぜることができます。別々のパッケージが同じライブラリを含んでいる場合に衝突を防ぐことにも繋がります。パッケージとライブラリを全て分割してしまうという手もありますが、パッケージは古いバージョンのライブラリを必要とすることがあるので動作する保証がありません。jar からファイルを抽出しないと Eclipse はファイルを認識せず、プラグインのインストール自体が上手くいきません。これは Eclipse がアップデートサイトとローカルインストールを別々に扱っているのが原因です (何故か言われても、そうなっているからとしか言えません)。
build() 関数
まず cd ${srcdir}
コマンドに注意してください。基本的にソースアーカイブは features
と plugins
フォルダを ${srcdir}
の直下に展開しますが、いつもそうだとは限りません。デファクトスタンダードから外れるプラグインの場合、行を変更する必要があります。
リリースされた一部の機能には、そのソースも含まれています。通常のリリースバージョンの場合、これらのソースは必要ないため、削除できます。さらに、同じ機能には *.pack.gz
ファイルが含まれており、jar アーカイブと比較して同じファイルが含まれています。 したがって、これらのファイルも削除できます。
次は features
セクションです。jar ファイルごとに必要なディレクトリを作成し、対応するディレクトリに jar を抽出します。 同様に、plugins
セクションでは、jar ファイルをディレクトリにインストールします。while サイクルは、おかしな名前のファイルを防ぐために使用されます。
トラブルシューティング
- Eclipse のクリーニングがいくつかの問題の修復に役立つ場合があります:
$ eclipse -clean
- 新しくインストールされたプラグインが Eclipse に表示されない場合は、既存のディレクトリの名前を変更するなどして、クリーンな
~/.eclipse
ディレクトリを試してください。もちろん、これにより、ユーザーがマーケットプレイス経由でインストールしたすべてのプラグインが使用できなくなることに注意してください。