Eclipse p2 Droplets in Rawhide

So p2 Droplets have been in Rawhide for a little while now, and since then we’ve converted most Eclipse plugins to build using the new format. With the exception of some cases that will be done manually, pretty much everything building with the XMvn macros (%mvn_build, %mvn_install) is guaranteed to be a p2 Droplet after a rebuild. We still support the old format (Dropins), and an installation on rawhide can detect both types, but the goal is to switch completely to Droplets.

If you’re unfamiliar with the term, you can think of p2 Droplets as a new way of packaging one or more Eclipse features. It contains the same jars and feature folders as before but with an additional file (fragment.info) containing some extra data.

The main reason for the switch was that Dropins (using the p2 Reconciler) has been deprecated for a while and has made it much more difficult to diagnose issues when it fails. Eclipse’s first launch actually caches a lot of data to make subsequent ones much faster, and the Reconciler can be a large chunk of that time. I have actually run into cases where installing just an extra package can take the first startup from around 10 seconds, to 3 minutes!

Testing was done with the following setup :

  • Fedora Rawhide Virtual Machine
  • ~700 OSGi bundles on the system
  • ~430 of these bundles to be tested through the Dropins and Droplets approaches
for i in {1..5}; do rm -rf $HOME/.eclipse/ ; (echo exit; echo y;) | /usr/bin/time -f "%E" eclipse -noexit -console ; done;

To test under Dropins, we simply took all the bundles packaged as Droplets and removed their ‘fragment.info’ file, along with the ‘p2.fragments’ line in ‘/etc/eclipse.ini’, just to be sure we completely disabled the new logic.

So what were the results ? Under Dropins, the average startup time was 17.63 seconds, and under Droplets, it was 9.44 seconds. The variance was very small, and nearly the same for both cases so there’s strong evidence that Droplets will be saving a lot of time on Eclipse’s first startup. Of course all subsequent launches (where $HOME/.eclipse is kept) would be much faster (~2s).

So one might ask what’s happened with all the work the Reconciler used to do.

  1. Fedora maintainers do a good job of making sure packages are using the latest version of a library even when upstream isn’t. As a result, things like the Reconciler aren’t as necessary in attempting to satisfy dependencies across different versions
  2. A lot of the logic to calculate dependencies and produce a self-sustaining package is done properly at build-time, and rightfully so because that’s where the provides/requires are generated.

We’ve been working on this change, along with the other aspects of simplifying Eclipse plugin packaging for a while now so it’s nice to see some easy wins immediately from adoption.

Sharing directories over a network with sshfs

Occasionally, you may find yourself in a situation where you need to access files from another machine on your network. As an example, I use Eclipse Mylyn for managing a large amount of bugs I care about, across various bug tracking systems. I keep this data in one central location and it’s simple enough to share across Eclipse workspaces on the same machine. But what if you want to access that data from another machine ?

In cases where things haven’t been set up ahead of time to allow for NFS (and to be honest, I haven’t really used NFS in a while) one can get away with using SSHFS (an already running SSH daemon seems more common). However, if the network is already trusted, then encrypting that data is just slowing things down. Although we can’t disable encryption outright, we can certainly optimize for speed by choosing a fast cipher.

For the purpose of this post, we assume that both machines communicate over a trusted network.

$ sshfs -o Ciphers=arcfour -o Compression=no user@ /tmp/mylyn-data

From here, we can pass /tmp/mylyn-data as the task directory for Eclipse Mylyn.
If you ever find your ssh connection has been improperly terminated while the mount point was active, one might need to issue the following command to properly unmount.

$ fusermount -u /tmp/mylyn-data

Get To Know A Command : jdeps

Well time sure flies. I can’t believe I haven’t made a post since the end of last year. It’s been quite busy these past few months but I’d like to think I haven’t completely dropped off the map in terms of Fedora contributions.

Today I’d like to talk about ‘jdeps’. It’s such an awesome tool for helping visualize dependencies. A little while ago I needed to convert about 30 Java packages to proper OSGi bundles (with proper Import-Package statements) and this tool really simplified the task.

mvn -DincludeScope=runtime depdendency:copy-depdendencies
jdeps -dotoutput=result/ target/dependency/*.jar

If you only care about dependencies at the jar level (using Require-Bundle), then you can even add a ‘-s’ flag to jdeps. The tool is part of the Java OpenJDK Development package (eg. java-1.8.0-openjdk-devel) shipped within Fedora.

As an example, it was quite easy to generate a nice dependency graph of the java library docker-client.


Get every new post delivered to your Inbox.