Eclipse 插件包指南

Arch 软件包指南

32 位 – CLR – CMake – Cross – DKMS – Eclipse – Electron – 字体 – Free Pascal – GNOME – Go – Haskell – Java – KDE – 内核模块 – Lisp – Meson – MinGW – Node.js – 非自由软件 – 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/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-插件名称，以便它们可以被识别为与 Eclipse 相关的软件包，并且可以使用简单的 shell 替换（如 ${pkgname/eclipse-}）轻松提取插件名称，而无需使用不必要的 ${_realname} 变量。插件名称对于在安装期间整理所有内容并避免冲突是必要的。

文件

提取

一些插件需要从 jar 文件中提取 features。已经包含在 JRE 中的 jar 实用程序用于执行此操作。但是，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 必须解压，因为 Eclipse 否则无法检测到它们，并且整个插件安装将无法工作。发生这种情况是因为 Eclipse 对待更新站点和本地安装的方式不同（不要问为什么，它就是这样）。

build() 函数

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

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

接下来是 features 部分。它为每个 jar 文件创建一个必要的目录，并将 jar 提取到相应的目录中。同样，plugins 部分将 jar 文件安装到它们的目录中。使用 while 循环是为了防止出现命名奇怪的文件。

故障排除

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