Eclipse plugin package guidelines

Arch package guidelines
32-bit
–
CLR
–
CMake
–
Cross
–
DKMS
–
Eclipse
–
Electron
–
Font
–
Free Pascal
–
GNOME
–
Go
–
Haskell
–
Java
–
KDE
–
Kernel modules
–
Lisp
–
Meson
–
MinGW
–
Node.js
–
Nonfree
–
OCaml
–
Perl
–
PHP
–
Python
–
R
–
Ruby
–
Rust
-
Security
–
Shell
–
VCS
–
Web
–
Wine
There are many ways to install working
Eclipse
plugins, especially since the introduction of the
dropins
directory in Eclipse 3.4, but some of them are messy, and having a standardized and consistent way of packaging is very important to lead to a clean system structure. It is not easy, however, to achieve this without the packager knowing every detail about how Eclipse plugins work. This page aims to define a standard and simple structure for Eclipse plugin
PKGBUILDs
, so that the filesystem structure can remain consistent between all plugins without having the packager to start again for every new package.
Eclipse plugin structure and installation
The typical Eclipse plugin contains two directories,
features
and
plugins
, and since Eclipse 3.3 they could only be placed in
/usr/lib/eclipse/
. The content of these two directories could be mixed with that of other plugins, and it created a mess and rendered the structure difficult to manage. It was also very difficult to tell at a glance which package contained which file.
This installation method is still supported in Eclipse 3.4, but the preferred one is now using the
/usr/lib/eclipse/dropins/
directory. Inside this directory can live an unlimited number of subdirectories, each one containing its own
features
and
plugins
subdirectories. This allows to keep a tidy and clean structure, and should be the standard packaging way.
Packaging
Sample PKGBUILD
Here is an example, we will detail how to customize it below.
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
}
How to customize the build
The main variable which needs to be customized is the
pkgname
. If you are packaging a typical plugin, then this is the only thing you need to do: most plugins are distributed in zip files which only contain the two
features
and
plugins
subdirectories. So, if you are packaging the
foo
plugin and the source file only contains the
features
and
plugins
, you just need to change
pkgname
to
eclipse-foo
and you are set.
Read on to get to the internals of the PKGBUILD, which help to understand how to setup the build for all the other cases.
In-depth PKGBUILD review
Package naming
Packages should be named
eclipse-
pluginname
, so that they are recognizable as Eclipse-related packages and it is easy to extract the plugin name with a simple shell substitution like
${pkgname/eclipse-}
, not having to resort to an unneeded
${_realname}
variable. The plugin name is necessary to tidy up everything during installation and to avoid conflicts.
Files
Extraction
Some plugins need the features to be extracted from jar files. The
jar
utility, already included in the JRE, is used to do this. However,
jar
cannot extract to directories other than the current one: this means that, after every directory creation, it is necessary to
cd
inside it before extracting. The
${_dest}
variable is used in this context to improve readability and PKGBUILD tidiness.
Locations
As we said, source archives provide two directories,
features
and
plugins
, each one packed up with jar files. The preferred dropins structure should look like this:
/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
This structure allows for mixing different versions of libraries that may be needed by different plugins while being clear about which package owns what. It will also avoid conflicts in case different packages provide the same library. The only alternative would be splitting every package from its libraries, with all the extra fuss it requires, and it would not even be guaranteed to work because of packages needing older library versions.
Features have to be unjarred since Eclipse will not detect them otherwise, and the whole plugin installation will not work. This happens because Eclipse treats update sites and local installations differently (do not ask why, it just does).
The build() function
First thing to be noticed is the
cd ${srcdir}
command. Usually source archives extract the
features
and
plugins
folders directly under
${srcdir}
, but this is not always the case. Anyway, for most non-
(de facto)
-standard plugins this is the only line that needs to be changed.
Some released features include their sources, too. For a normal release version these sources are not needed and can be removed. Furthermore same features include
*.pack.gz
files, which contain the same files compared to the jar archives. So these files can be removed, too.
Next is the
features
section. It creates the necessary directories, one for every jar file, and extracts the jar in the corresponding directory. Similarly, the
plugins
section installs the jar files in their directory. A while cycle is used to prevent funny-named files.
Troubleshooting
Sometimes cleaning of Eclipse helps to repair some problems:
$ eclipse -clean
If new installed plugins do not appear in Eclipse, try with a clean
~/.eclipse
directory, for example by renaming the existing one. Be aware that this will of course make all the user-installed plugins via Marketplace unavailable.