Including a JRE in a Tycho build
July 31, 2012 2 Comments
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.
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
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
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.