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

提供: ArchWiki
ナビゲーションに移動 検索に移動
(en:Eclipse plugin package guidelinesへの転送ページ)
 
(序文を更新)
 
(3人の利用者による、間の4版が非表示)
1行目: 1行目:
  +
[[Category:パッケージ開発]]
−
#redirect[[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]]
  +
{{Package Guidelines}}
  +
  +
特に Eclipse 3.4 での ''dropins'' ディレクトリの導入以来、動作する [[Eclipse]] プラグインをインストールする方法はたくさんありますが、それらの中には面倒なものもあり、クリーンなシステム構造を実現するには、標準化された一貫したパッケージ化方法を持つことが非常に重要です。ただし、パッケージャが 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>}} の直下に展開しますが、いつもそうだとは限りません。デファクトスタンダードから外れるプラグインの場合、行を変更する必要があります。
  +
  +
リリースされた一部の機能には、そのソースも含まれています。通常のリリースバージョンの場合、これらのソースは必要ないため、削除できます。さらに、同じ機能には {{Ic|*.pack.gz}} ファイルが含まれており、jar アーカイブと比較して同じファイルが含まれています。 したがって、これらのファイルも削除できます。
  +
  +
次は {{Ic|features}} セクションです。jar ファイルごとに必要なディレクトリを作成し、対応するディレクトリに jar を抽出します。 同様に、{{Ic|plugins}} セクションでは、jar ファイルをディレクトリにインストールします。while サイクルは、おかしな名前のファイルを防ぐために使用されます。
  +
  +
== トラブルシューティング ==
  +
  +
* Eclipse のクリーニングがいくつかの問題の修復に役立つ場合があります: {{bc|$ eclipse -clean}}
  +
* 新しくインストールされたプラグインが Eclipse に表示されない場合は、既存のディレクトリの名前を変更するなどして、クリーンな {{ic|~/.eclipse}} ディレクトリを試してください。もちろん、これにより、ユーザーがマーケットプレイス経由でインストールしたすべてのプラグインが使用できなくなることに注意してください。

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

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

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 3.4 での dropins ディレクトリの導入以来、動作する Eclipse プラグインをインストールする方法はたくさんありますが、それらの中には面倒なものもあり、クリーンなシステム構造を実現するには、標準化された一貫したパッケージ化方法を持つことが非常に重要です。ただし、パッケージャが 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 ディレクトリを試してください。もちろん、これにより、ユーザーがマーケットプレイス経由でインストールしたすべてのプラグインが使用できなくなることに注意してください。
「https://wiki.archlinux.jp/index.php?title=Eclipse_プラグインパッケージガイドライン&oldid=32521」から取得