Magellan/Design/Creating Eclipse RPMs

Creating Eclipse RPMs

Creating RPMs for Eclipse plugins is not as straightforward as it might seem initially. In my experience, downloadable Eclipse plugins are often the result of a build process that Eclipse facilitates that may include many interleaved steps such as checking out code, generating required files, compilation of source files, creation of jars, moving or copying files or directories from one location to another, running automated test suites, and more.

The particular problem stems from the interleaving of steps and the asusmption of network connectivity. The Eclipse build process may be very useful for plugin developers, but it is a bit complicated for packagers.

Packagers should assume that build servers will not have network connectivity, so therefore a complete source tarball must be provided; the build scripts cannot fetch the sources during the build step. If you are using Build.RPM when you package your RPMs, as you should on SUSE Linux, you should assume that you will not be able to access the network during the build of an RPM - you will need to fetch all of the sources first.

In short, cleanly and properly splitting the fetching of sources from the building of sources can sometimes be a challenge with Eclipse plugins.

This article addresses the potential problems that can arise from creating RPMs for Eclipse plugins. In this article, the example we will be using is that of building the Eclipse Modeling Framework (EMF) as an RPM.

Check Functionality

Before writing a single line of code, first find out whether the plugin in question actually works with Eclipse, and what versions of Eclipse it works with.

Checking The Plugin Against The Current Eclipse RPM

You might want to check the plugin against the currently installed Eclipse RPM, if you have one. There is no magic to an Eclipse installation. On SUSE Linux, the entire Eclipse installation is located beneath the directory /usr/share/eclipse. If you like, you can create a tarball from this directory and make a sandbox installation anywhere else on your system that you like. Or, you can probably obtain a full version of the Eclipse SDK from the Eclipse Website.

Take your Eclipse SDK tarball and unpack that into a different location where you can play around and blow it away later.

Now that you have a sandbox Eclipse location, obtain a copy of the plugin you want to make into an RPM. Download the plugin and unpack it in your sandbox location. Then run Eclipse from there, and see if it works as you expected.

Once you've done this, then you know that the plugin actually does work with Eclipse. It would be a waste of time to try to debug your RPM if the code itself doesn't work.

If The Plugin Doesn't Work

There are a few possible causes for your downloaded plugin to not work - or not appear to work.

• Check to make sure you are running the same version of Eclipse where the plugin is installed.
• Check versions. The plugin you downloaded might not work with the version of Eclipse you are using. In particular, if you are using the RPM version of Eclipse, it might not be as current as the plugin you are testing. You can try downloading a stream build of Eclipse instead. These builds are not assumed to be as stable, but are usually more current.
• What is the expected behavior? Some plugins, like EMF, are primarily just class library support for other plugins, and don't visibly alter the Eclipse IDE by themselves.

Building From Source

Now that you have assurance that the plugin works, the next step is to try to build the whole plugin from source. For official Eclipse plugins, it seems that a common way to do this is to check out a release engineering module from CVS first. Then you run the build script, which checks out the additional code and runs the build.

For other third-party plugins, the mechanism may differ.

In any case, you need to check out the sources and build the plugin from scratch. You may need to consult with the project owner(s) to determine the correct way to do this.

In my case, I know that EMF is a part of the Eclipse Tools project and is located in Eclipse's /home/tools directory on their CVS server. I can check out the release engineering module for EMF like this:

cvs -z3 -d:pserver:anonymous@dev.eclipse.org:/home/tools co org.eclipse.gef.releng

At this point, my practice is to create a script that will evolve into one that creates my source tarball for me. There will be several steps to this process. This will make better sense later; for now, just trust me on this.

Since I'm working on EMF, I will create a simple BASH script called make_emf_tarball.sh. There is nothing fancy about this script. It just systemitizes the steps required to get the source. For now, it just includes the commands to fetch from source.