Including a JRE in a Tycho build

In Eclipse, a JRE can be added to a product build by selecting the right check box in the product editor. During the product export the jre will be copied into the build output. However the JRE is found using the set defined in the “installed JREs” list. Tycho does not have an “installed JRE” list and cannot use the same mechanism. Another method must be used instead.

The bundle JRE checkbox in the product editor

A commonly quoted way is to use root files. Tycho supports a subset of the full PDE definition – but enough for most use cases. In a feature project you place the JRE as a sub-directory (or directories if you want to support multiple platforms). In the build.properties you specify the directory and, for multiple platforms, the platform filter. The destination directory needs to be called ire as the launcher executable knows to look their for the JRE. For example to include the Windows 64-bit JRE then add the following line to your build.properties and place the JRE in a directory called rootfiles/win-64/jre.

root.win32.win32.x86_64 = rootfiles/win-64

This works well for the initial build. However the problem with this approach occurs when you attempt to update you JRE on a windows platform. On windows you cannot remove a file which is open – this includes executables and DLLs in use by running applications such as eclipse.exe and the JRE DLLs.

An alternative approach is the use the recently added p2 touchpoint instruction – setJvm. Instead of using root files the JRE is bundled directly in the feature like any other resource. This of course means the JRE is no longer in the root of the application in the jre directory. Instead it is contained within the exploded feature directory. However we can use the setJvm p2 instruction to tell p2 to set the jvm argument in the launcher ini file to point to the JRE in our feature. When you update the feature the new JRE will be in a new feature directory and subsequent calls to setJvm will overwrite the previous one. Calling setJvm with the string null will remove the jvm line. This is useful should the feature be uninstalled, the eclipse launcher can revert back to it’s default search algorithm.

To use this an additional file is required called p2.inf link. This is a special file used by p2 to perform aditonal operations such as configuring jvm paths. We need to create this file with two lines. The first specifies the jvm path to use when the feature is installed – this can be a relative path. The second removes the jvm argument on uninstall of the feature.

instructions.configure=\
org.eclipse.equinox.p2.touchpoint.eclipse.setJvm(jvm:features/feature-name_1.0.0/jre/bin);
instructions.unconfigure=\
org.eclipse.equinox.p2.touchpoint.eclipse.setJvm(jvm:null);

This assumes feature ID is feature-name and the version number is 1.0.0. The path is relative to the product root – features/ is the normal features directory. For Tycho we also need to add the p2.inf to the build.properties file under the bin.includes list.

The advantage of this approach is that the content is bundled with the feature – if you copy the feature you get the JRE – you just loose the p2 hook if you manually install the feature. Where-as with root-files, the JRE is separate to the feature definition. If you look at a p2 repository which contains a feature with root-files you will see in addition to the normal “plugins” and “features” directories another one called “binary” which contains the extra content.

Unfortunately unlike root files, you need to create a features for each platform you support. While you could bundle it all in one feature you would install all the JREs at the same time. It would also not be possible to use the touchpoint instruction. Instead each JRE feature specifies the platform it will work on. Then a “master” JRE feature can specify all the platform features as optional dependencies. Your product only needs to reference this master feature and the appropriate platform JRE feature will also be installed (if present).
For example, add the following to your master feature.xml;

   <includes
         id="jre.win32.win32.x86"
         version="0.0.0"
         optional="true"
         os="win32"
         ws="win32"
         arch="x86"/>

The only piece left is to obtain the JRE itself. Unfortunately the Oracle JRE’s cannot be downloaded direct from Orcale automatically (see e.g. here) so they must be manually downloaded, installed and the the jre directory copied across for each version and platform you need to support.

About these ads

2 Responses to Including a JRE in a Tycho build

  1. Hi I tried your solution using the different features grouped under a “parent” one.
    It seems to work fine, and it is exactly what I want. I need to be able to update the JRE if needed with the release of a newer version of the dedicated feature.

    The problem that I’m facing right now is related to permissions on the files that are copied from the original feature location to the final product one.
    I explained a bit in here: http://dev.eclipse.org/mhonarc/lists/tycho-user/msg04624.html

    Did you verify any kind of problems? In Windows it is no big deal, but in Linux and Mac OS X the issue prevents launching the RCP Product. Any hints on that?

    Best regards,
    Massimo.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: