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

提供: ArchWiki
ナビゲーションに移動 検索に移動
(en:Eclipse plugin package guidelinesへの転送ページ)
 
1行目: 1行目:
  +
[[Category:パッケージ開発]]
−
#redirect[[en:Eclipse plugin package guidelines]]
  
  +
[[en:Eclipse plugin package guidelines]]
  +
[[it:Eclipse plugin package guidelines]]
  +
[[zh-cn:Eclipse plugin package guidelines]]
  +
{{Package Guidelines}}
  +
  +
[[Eclipse]] プラグインをインストールする方法は多数存在します。特に Eclipse 3.4 で ''dropins'' ディレクトリが導入されてから方法は増えました。しかしながら、中には汚いインストール方法もあるので、システムの構造を綺麗に保つためにパッケージングには標準的で首尾一貫した方法が必要です。Eclipse プラグインがどうやって動作するのか詳しい知識がないパッケージ作成者にとっては容易なことではありません。このページでは Eclipse プラグインの [[PKGBUILD]] の標準的でシンプルな構造を定義することで、ファイルシステムの構造を壊さないようにしつつ、パッケージを作成するときに毎回初めからやりなおさなくてもいいようにすることを目指しています。
  +
  +
== Eclipse プラグインの構造とインストール ==
  +
基本的に Eclipse プラグインには2つのディレクトリが存在します: {{ic|features}} と {{ic|plugins}}。Eclipse 3.3 からプラグインが置ける場所は {{ic|/usr/lib/eclipse/}} と決まっていました。しかし、この2つのディレクトリの中身が他のプラグインの中身と混ざってしまうことがあり、そうなるともう手がつけられなくなって構造の管理が難しくなります。どのパッケージにどのファイルが含まれているのか確認するのは非常に困難だったと言わざるをえません。
  +
  +
上記のインストール方法は Eclipse 3.4 ではまだサポートされていますが、現在推奨されている方法では {{ic|/usr/lib/eclipse/dropins/}} ディレクトリを使います。このディレクトリの中にはサブディレクトリをいくらでも作成することができ、各ディレクトリに {{ic|features}} と {{ic|plugins}} サブディレクトリが存在します。構造を小さく綺麗にまとめることができるので、新しい方法を標準的なパッケージング方法とするべきです。
  +
  +
== パッケージング ==
  +
  +
=== サンプル PKGBUILD ===
  +
以下がサンプルです。カスタマイズする方法を下で詳しく説明します。
  +
  +
{{hc|PKGBUILD-eclipse.proto|<nowiki>
  +
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
  +
}
  +
</nowiki>}}
  +
  +
=== ビルドをカスタマイズする方法 ===
  +
カスタマイズする必要があるメインの変数は {{Ic|pkgname}} です。普通のプラグインをパッケージ化するときは、{{Ic|pkgname}} を変更するだけでパッケージが作れます。ほとんどのプラグインは zip ファイルで配布されていて {{ic|features}} と {{ic|plugins}} サブディレクトリだけを含んでいます。例えば、{{Ic|foo}} プラグインをパッケージする場合、ソースファイルに {{ic|features}} と {{ic|plugins}} しか含まれていなければ、{{Ic|pkgname}} を {{Ic|eclipse-foo}} に変更するだけで準備が整います。
  +
  +
PKGBUILD の内部で何をやっているかは以下を読み進めてください。様々なパッケージでビルドをセットアップする方法を理解するのに役立つはずです。
  +
  +
=== PKGBUILD の解説 ===
  +
  +
==== パッケージの命名 ====
  +
Eclipse 関連のパッケージとわかるようにパッケージの名前は {{Ic|eclipse-''pluginname''}} としてください。不必要な {{Ic|<nowiki>${_realname}</nowiki>}} 変数を使うことなく、{{Ic|<nowiki>${pkgname/eclipse-}</nowiki>}} などの簡単なシェルの置換でプラグインの名前を簡単に抽出できます。インストール時のあらゆることをまとめて、衝突を避けるために、プラグインの名前は必須です。
  +
  +
==== ファイル ====
  +
  +
===== 抽出 =====
  +
プラグインによっては jar ファイルからの抽出が必要です。JRE に含まれている {{Ic|jar}} ユーティリティを使って抽出を行います。ただし、{{Ic|jar}} はカレントディレクトリ以外のディレクトリに抽出ができないので、ディレクトリを作成して、ディレクトリに {{Ic|cd}} してから抽出してください。{{Ic|<nowiki>${_dest}</nowiki>}} 変数を使うことで PKGBUILD の可読性を上げることができます。
  +
  +
===== 場所 =====
  +
先に述べたように、ソースアーカイブには2つのディレクトリ {{ic|features}} と {{ic|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() 関数 ====
  +
まず {{Ic|<nowiki>cd ${srcdir}</nowiki>}} コマンドに注意してください。基本的にソースアーカイブは {{ic|features}} と {{ic|plugins}} フォルダを {{Ic|<nowiki>${srcdir}</nowiki>}} の直下に展開しますが、いつもそうだとは限りません。デファクトスタンダードから外れるプラグインの場合、行を変更する必要があります。
  +
  +
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.
  +
  +
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.

2016年1月12日 (火) 17:34時点における版

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

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} の直下に展開しますが、いつもそうだとは限りません。デファクトスタンダードから外れるプラグインの場合、行を変更する必要があります。

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 *.pack.gz files, which contain the same files compared to the jar archives. So these files can be removed, too.

Next is the features section. It creates the necessary directories, one for every jar file, and extracts the jar in the corresponding directory. Similarly, the plugins section installs the jar files in their directory. A while cycle is used to prevent funny-named files.

「https://wiki.archlinux.jp/index.php?title=Eclipse_プラグインパッケージガイドライン&oldid=4754」から取得