Col senno di poi

Arch Linux Eclipse plug-in packaging: a proposal

Eclipse plugins are basically structured the same, but there has never been a standardization proposal to make them consistent and easy to package. It took some time for me to fully understand how the Eclipse plug-in system actually works, especially since Ganymede’s coming, and even more time to develop a PKGBUILD prototype that would fit most plugins with minor modifications. Here’s the result of this work, for which I surely have to thank Jonathan Wiersma: he’s been really great in helping me in this matter.

1. The PKGBUILD

Long story short, here’s the code, I’ll comment most important choices later on. I’m using eclipse-mylyn as an example.

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')

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

  cd ${srcdir}

  # Features
  find features -type f -name *.jar | while read _feature ; do
    if [[ ${_feature} =~ (.*\.jar$) ]] ; then
      install -dm755 ${_dest}/${_feature%*.jar}
      cd ${_dest}/${_feature/.jar}
      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
}

2. Package naming and makedepends

Packages should be named eclipse-pluginname, so that they’re recognizable as eclipse-related packages and it’s easy to extract the plugin name with a simple shell substitution like ${pkgname/eclipse-}, not having to resort to the unneded ${_realname} variable. The plugin name is necessary to tidy up everything during installation and avoid conflicts.

I tried using bsdtar instead of unzip to remove the make dependency, but the test was negative: the archives I tried spitted out lots of errors, so I went the easy way. If someone makes it with bsdtar, I’ll be glad to modify the script.
UPDATE: I was noticed that I can directly use jar, which the user already has since it’s part of the JRE. This is great, since it spares a makedepend! However, jar can’t extract to directories other than the current one: this means that, after the directory creation, it’s necessary to cd before extracting. Since there were many occurrences of the destination path I decided to use a custom variable even though somebody might not like it, because there’s a great improvement in readability.

3. File locations

Eclipse 3.4 (Ganymede) introduced a new way of handling plugins: the dropins folder (located in /usr/share/eclipse/dropins). Eclipse scans this folder looking for plugins, and it supports many directory structures. Source archives provide two directories, features and plugins, each one packed up with jar files. The preferred dropins structure should look like this:

/usr/share/eclipse/dropins/pluginname/features/feature1/…
/usr/share/eclipse/dropins/pluginname/features/feature2/…
/usr/share/eclipse/dropins/pluginname/plugins/plugin1.jar
/usr/share/eclipse/dropins/pluginname/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 wouldn’t even be guaranteed to work because of packages needing older library versions.
Features have to be unjarred since Eclipse won’t detect them otherwise, and the whole plugin installation won’t work. This happens because Eclipse treats update sites and local installations differently (don’t ask me why, it just does).

3. 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.
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

4. Conclusions

So here it is. I hope it’s clear why I’m proposing to standardize Eclipse plugins, and why I took certain routes instead of others. I know it looks a bit complicated for a prototype PKGBUILD, but I think it’s the best way to handle all the problems I’ve encountered. Comments, improvements and corrections are, as always, very welcome.

Posted by bardo under arch,english,g33k1ng around | Comments (0)