「Eclipse プラグインパッケージガイドライン」の版間の差分

2023年6月29日 (木) 21:03時点における版

パッケージ作成ガイドライン

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 ディレクトリを試してください。もちろん、これにより、ユーザーがマーケットプレイス経由でインストールしたすべてのプラグインが使用できなくなることに注意してください。

@@ 86行目: / 86行目: @@
 ==== build() 関数 ====
 まず {{Ic|<nowiki>cd ${srcdir}</nowiki>}} コマンドに注意してください。基本的にソースアーカイブは {{ic|features}} と {{ic|plugins}} フォルダを {{Ic|<nowiki>${srcdir}</nowiki>}} の直下に展開しますが、いつもそうだとは限りません。デファクトスタンダードから外れるプラグインの場合、行を変更する必要があります。
+リリースされた一部の機能には、そのソースも含まれています。通常のリリースバージョンの場合、これらのソースは必要ないため、削除できます。さらに、同じ機能には {{Ic|*.pack.gz}} ファイルが含まれており、jar アーカイブと比較して同じファイルが含まれています。  したがって、これらのファイルも削除できます。
-Some released features include their sources, too. For a normal release version these sources are not needed and can be removed. Furthermore same features include {{Ic|*.pack.gz}} files, which contain the same files compared to the jar archives. So these files can be removed, too.
+次は {{Ic|features}} セクションです。jar ファイルごとに必要なディレクトリを作成し、対応するディレクトリに jar を抽出します。  同様に、{{Ic|plugins}} セクションでは、jar ファイルをディレクトリにインストールします。while サイクルは、おかしな名前のファイルを防ぐために使用されます。
+== トラブルシューティング ==
+* Eclipse のクリーニングがいくつかの問題の修復に役立つ場合があります: {{bc|$ eclipse -clean}}
-Next is the {{Ic|features}} section. It creates the necessary directories, one for every jar file, and extracts the jar in the corresponding directory. Similarly, the {{Ic|plugins}} section installs the jar files in their directory. A while cycle is used to prevent funny-named files.
+* 新しくインストールされたプラグインが Eclipse に表示されない場合は、既存のディレクトリの名前を変更するなどして、クリーンな {{ic|~/.eclipse}} ディレクトリを試してください。もちろん、これにより、ユーザーがマーケットプレイス経由でインストールしたすべてのプラグインが使用できなくなることに注意してください。