Eclipse 插件打包準則 - Arch Linux 中文维基

跳至內容

# Eclipse 插件打包準則

出自 Arch Linux 中文维基
翻譯狀態：

- 本文（或部分內容）譯自 Eclipse plugin package guidelines，最近一次同步於 2015-03-13，若英文版本有所更改，則您可以幫助同步與翻譯更改的內容。
- 您可以在 ArchWiki 的對應頁面找到本文翻譯的原始修訂歷史。
- 本文可能與英文原文存在出入。

Arch 打包準則

32 位 – 安全 – CLR – CMake – DKMS – Eclipse – Electron – Free Pascal – GNOME – Go – Haskell – Java – 交叉編譯工具 – KDE – Lisp – Meson – MinGW – 內核模塊 – Node.js – Nonfree – OCaml – Perl – PHP – Python – R – Ruby – Rust – Shell – 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 循環用於防止生成名字奇怪的文件。

分類：​

- 包開發

Eclipse 插件打包準則
新增話題