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


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 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;


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.


8 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:

    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,

  2. Tommy says:

    I tried your second solution with the features. I created a parent feature and 4 child features (I want to support 4 operating systems). My parent feature contains the child features as “Included Features”. The feature.xml looks as follows:

    label="Integrated Java"

    No license

    A feature looks like this:

    No license

    And the of a feature looks like this:
    bin.includes = feature.xml,\

    while jre is the folder containing the JRE for the particular operating system.
    My product has the “IntegratedJava” feature (master feature) as Dependency.
    The p2.inf of the product looks like yours:

    Ok now my problem:
    When I build the product I always get 2 features: the parent feature “IntegratedJava” as well as the feature of the particular os e.g. “IntegratedJava_win32_x86_64”. This child feature now contains the jre while the parent feature doesn’t.
    I kinda thought that the JRE should be located in the parent feature which name is always the same independent from the operating system. Otherwise the setJvm instruction in the p2.inf will never find a JRE in the parent feature folder. I also thought that the child feature should not be present as a seprate feature in the features folder
    Do I misunderstand something in your proposal?

    Feedback is appreciated. Greetings.

    • Tommy says:

      The system kinda removed some of the text.
      Here is the feature.xml of the parent feature again (hopefully escaping brackets works):

      No license






      And here the xml of a child feature:

      No license


  3. Tommy says:

    Well obviously it didn’t work. Hopefully you understand my problem anyway.

    • drsgoodall says:

      Hi. The parent feature just aggregates the various platform specific child features together allowing the platform filters and optional flags to be set. This is not possible in the .product file. The child features contain the jre and p2.inf files. These are not rolled into the patent but installed as separate features. In the eclipse/rcp about dialog you should see the child feature nested under the parent.

  4. Paul Roubekas says:

    Is this approach valid anymore? I am working with with a Neon (4.6.0) based RCP and it does not seem to work. I get the following during the Tycho build….

    Caused by: org.eclipse.tycho.artifacts.DependencyResolutionException: eclipse-feature artifact with ID “jre.linux.gtk.x86_64.Feature” and version matching “0.0.1” was not found in the target platform

    • drsgoodall says:

      Hi. I still use this approach. However I have not tried a neon based build yet, but I have no reason to see why it would not work. In fact it is changes related to Tycho that would cause failures rather than the eclipse version you are building against.

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

%d bloggers like this: