Eclipse 插件打包準則

Arch 打包準則

32 位 – CLR – CMake – Cross – DKMS – Eclipse – Electron – Font – Free Pascal – GNOME – Go – Haskell – Java – KDE – 內核模塊 – Lisp – Meson – MinGW – Node.js – Nonfree – OCaml – Perl – PHP – Python – R – Ruby – Rust – VCS – Web – Wine

有許多安裝有效 Eclipse 插件的方法。尤其是在 Eclipse 3.4 裡引入 dropins 文件夾之後。但其中一些比較凌亂，而且具有標準化和一致的封裝方法對於一個乾淨的系統結構是非常重要的。然而，如果沒有一個對 Eclipse 插件如何工作一清二楚的打包者的話，要實現這一切並不簡單。本文試圖定義一個標準且精簡的 Eclipse 插件 PKGBUILD 的結構，如此來在不用麻煩打包者全部重新打包的情況下保持一個乾淨的文件系統結構。

Eclipse 插件結構以及安裝[編輯 | 編輯原始碼]

一般的 Eclipse 插件包含兩個目錄，features 和 plugins, 自從 Eclipse 3.3 起它們只能放在 /usr/share/eclipse/. 這兩個文件夾的內容可以與其他插件的混合，如此會導致混亂並且結構難以管理，也很難來一目了然地區分哪個軟件包包含哪些文件。

這種安裝方法依然被 Eclipse 3.4 支持，然而我們更推薦使用 /usr/share/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=('i686' 'x86_64')
url="http://www.eclipse.org/mylyn/"
license=('EPL')
depends=('eclipse')
optdepends=('bugzilla: ticketing support')
source=(http://download.eclipse.org/tools/mylyn/update/mylyn-${pkgver}-e3.4.zip)
md5sums=('e98cd7ab3c5d5aeb7c32845844f85c22')

prepare() {
  # remove features and plug-ins containing sources
  rm features/*.source_*
  rm plugins/*.source_*
  # remove gz files
  rm plugins/*.pack.gz
}

package() {
  _dest=${pkgdir}/usr/share/eclipse/dropins/${pkgname/eclipse-}/eclipse

  # Features
  find features -type f | while read _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 _plugin ; do
    install -Dm644 "${_plugin}" "${_dest}/${_plugin}"
  done
}

如何自定義[編輯 | 編輯原始碼]

需要修改的，最主要的變量就是 pkgname. 如果你要打包一個一般的插件，那麼你只需要做這些: 大部分插件以 zip 文件發佈，其中只含有 features 和 plugins 子目錄。所以，如果你要打包 foo 插件並且源文件只包含 features 和 plugins, 只需把 pkgname 改成 eclipse-foo, 這樣就完成了。

請仔細閱讀，獲取 PKGBUILD 的內部結構，這能幫助你理解在其他情況下如何設置編譯。

深入分析 PKGBUILD[編輯 | 編輯原始碼]

包的命名[編輯 | 編輯原始碼]

包應該命名為 eclipse-pluginname, 如此能被識別為 Eclipse 相關軟件包並且能輕鬆使用 shell 替代來提取出如 ${pkgname/eclipse-} 的插件名稱，而不用使用不需要的 ${_realname} 變量。插件名對於清理安裝時臨時文件並避免衝突是必需的。

文件[編輯 | 編輯原始碼]

解壓[編輯 | 編輯原始碼]

一些插件需要的功能要從 jar 文件中提取。已包含於 JRE 的 jar 工具,就是用來幹這個的。然而，jar 並不能解壓到當前目錄以外的地方: 這意味着，創建每個目錄之後，在解壓之前需要 cd 進入該目錄。${_dest} 變量被用在這樣的背景下，以提高文本可讀性和PKGBUILD整潔性。

地址[編輯 | 編輯原始碼]

如同我們所說，源文檔提供兩個目錄 features 和 plugins, 每個打包為 jar 文件。更好的嵌入式結構應該如下:

/usr/share/eclipse/dropins/pluginname/eclipse/features/feature1/...
/usr/share/eclipse/dropins/pluginname/eclipse/features/feature2/...
/usr/share/eclipse/dropins/pluginname/eclipse/plugins/plugin1.jar
/usr/share/eclipse/dropins/pluginname/eclipse/plugins/plugin2.jar

這種結構支持把不同插件需要的不同版本的庫混起來，同時很清楚它是屬於那個包的。這也能避免當不同插件提供了相同庫時的衝突。唯一的選擇是把每個包和它的庫一起它所需的一切亂七八糟的東西分離，並且你也別想這樣就能起效，因為有些包需要舊版的庫才能工作。必須要從 jar 裡解壓出來因為 Eclipse 不會自動檢測它們，不然的話整個安裝的插件都不會工作。這歸因於 Eclipse 認為更新站點和本地安裝是不同的 (別問為什麼，它就這樣).

build() 函數[編輯 | 編輯原始碼]

首先要注意的就是 cd ${srcdir} 命令。通常源壓縮文檔直接在 ${srcdir} 下解壓出 features 和 plugins 文件夾，但並不是所有的都這樣。總之，對大多數(事實上)非標準的插件這是需要改變的唯一路線。

某些特性也隨源碼發佈。對一個普通的釋出版來說源碼並不需要，可以刪除。更多的特性包含 *.pack.gz 文件，與 jar 文檔相比內容相同。所以這些文件也能刪除。

接下來是 features 部分。它為每個 jar 文件創建必要的目錄並解壓到對應的目錄去。同樣，plugins 部分把 jar 安裝到文件夾裡去。一個 while 循環用於防止生成名字奇怪的文件。