Eclipse 插件打包指南

安装可用的 Eclipse 插件有很多方法，尤其是在引入 dropins 目录后（Eclipse 3.4），但其中一些方法比较混乱，拥有一个标准化、一致的打包方式对于建立清晰的系统结构非常重要。然而，如果不让打包者了解 Eclipse 插件工作原理的每一个细节，要实现这一点并不容易。本页面旨在为 Eclipse 插件 PKGBUILD 定义一个标准、简单的结构，以便文件系统结构在所有插件之间保持一致，而无需打包者为每个新包重新开始。

Eclipse 插件结构与安装

典型的 Eclipse 插件包含两个目录：features 和 plugins，并且自 Eclipse 3.3 起，它们只能放置在 /usr/lib/eclipse/ 中。这两个目录的内容可以与其他插件的内容混杂在一起，这会造成混乱，并使结构难以管理。也很难一目了然地知道哪个包包含哪个文件。

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。如果您正在打包一个典型的插件，那么您只需要做这一件事：大多数插件都以 zip 文件形式分发，这些文件只包含 features 和 plugins 两个子目录。因此，如果您正在打包 foo 插件，并且源文件只包含 features 和 plugins，您只需要将 pkgname 改为 eclipse-foo 即可。

继续阅读以了解 PKGBUILD 的内部机制，这将有助于理解如何为所有其他情况设置构建。

深入 PKGBUILD 审查

包命名

软件包应命名为 eclipse-pluginname，以便它们被识别为 Eclipse 相关软件包，并且可以通过简单的 shell 替换（如 ${pkgname/eclipse-}）轻松提取插件名称，而无需诉诸不必要的 ${_realname} 变量。插件名称对于在安装过程中整理所有内容并避免冲突至关重要。

文件

解压

某些插件需要从 jar 文件中解压 features。jar 工具（已包含在 JRE 中）用于此操作。但是，jar 无法将文件解压到当前目录以外的其他目录：这意味着，在每次创建目录后，都有必要先 cd 到该目录中进行解压。${_dest} 变量在此上下文中使用，以提高可读性和 PKGBUILD 的整洁性。

位置

如前所述，源存档提供两个目录：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

这种结构允许混合不同版本的库，这些库可能被不同的插件所需，同时又能清晰地表明哪个包拥有什么。它还可以避免不同包提供相同库时发生的冲突。唯一的替代方法是将每个包与其库分开，这需要额外的麻烦，并且由于包需要旧版本的库，因此甚至不能保证有效。Features 必须解压（unjarred），否则 Eclipse 将无法检测到它们，整个插件安装将无法正常工作。发生这种情况是因为 Eclipse 对更新站点和本地安装的处理方式不同（不必问为什么，它就是这样工作的）。

build() 函数

首先要注意的是 cd ${srcdir} 命令。通常源存档会直接在 ${srcdir} 下解压 features 和 plugins 文件夹，但这并非总是如此。无论如何，对于大多数非（事实上）标准的插件，这只需要更改这一行。

一些已发布的 features 也包含其源代码。对于正常的发布版本，这些源代码是不需要的，可以删除。此外，有些 features 包含 *.pack.gz 文件，这些文件与 jar 存档包含相同的文件。因此，这些文件也可以删除。

接下来是 features 部分。它创建了必要的目录，每个 jar 文件一个目录，并将 jar 文件解压到相应的目录中。类似地，plugins 部分将 jar 文件安装到它们的目录中。一个 while 循环用于处理命名不规范的文件。

故障排除

有时清理 Eclipse 有助于修复一些问题
```
$ eclipse -clean
```
如果新安装的插件没有出现在 Eclipse 中，请尝试清理 ~/.eclipse 目录，例如通过重命名现有目录。请注意，这当然会使通过 Marketplace 安装的所有用户插件不可用。