Eclipse RCP product deployment. This tutorial describes how the product configuration file and the deployment of Eclipse applications. It also covers features.
A product configuration file (in a shorter form this is called: product ) defines the configuration of an Eclipse application. This includes icons, splash screen and the plug-ins or features included in your application.
A product always points to one application class. The default applications for Eclipse applications are:
org.eclipse.e4.ui.workbench.swt.E4Applicationfor Eclipse RCP applications not related to the IDE
org.eclipse.ui.ide.workbenchfor Eclipse IDE based applications
These are sufficient for lots of scenarios.
In case a customer wants to adjust the default Eclipse initialization logic they could also provide their own implementation, such implementation must implement the
A product is a development artifact and is not required at runtime.
A product is typically created in a separate project. In the Plug-in Development perspective you can create a new product configuration file via a right-click on a project and by selecting.
You can edit the product file via a special editor. The product extension and the containing plug-in can be defined in the Product Definition section. Eclipse RCP applications typically use the predefined E4Application but it is also possible to define a custom application via the org.eclipse.core.runtime.applications extension point.
On the Overview tab of this editor, you can start the product. Pressing the Synchronize link writes the relevant product configuration information into the plugin.xml file. Both settings are highlighted in the following screenshot.
It is possible to enter an ID for the product.
Avoid using the same ID for the product as for a plug-in as this might create problems during a product export.
Convention is to add the
.product extension to the ID.
On the Contents tab you can define the set of plug-ins or features which are included in the product, e.g., the plug-ins that are included if you start or export your product.
The Splash tab allows you to specify the plug-in which contains the splash screen. The name is predefined as splash.bmp and it must be located in the root of the plug-in directory. Therefore, you need to put a file called splash.bmp file into the project main directory. Currently Eclipse supports only Bitmap (.bmp) files.
The predefined name and location of the splash screen image can be changed via the osgi.splashPath parameter, the file name can be changed with the -showsplash path_to_file.
You can configure the launcher name and icon for your product. The launcher is the executable program that is created during the deployment of the product. A launcher is platform specific. For example, the default launcher is called eclipse.exe on the MS Windows platform. This launcher has also an icon associated with it. To change the name and the icon, select the Launching tab of your product configuration.
Here you can specify the file name of the launcher and the icon which should be used. Make sure the format of the icons is correct, otherwise Eclipse will not use them.
The icon configuration depends on the platform you are using. Eclipse allows you to export your application for multiple platforms and uses the correct ones based on your product configuration.
In the Launching Arguments section you can specify parameters for your Eclipse application and arguments for the Java runtime environment. Program Arguments are parameters passed to the Eclipse application.
Currently the splash handlers, which can be registered via the Customization part of the Splash tab are not supported by the Eclipse 4 standard. Also, the configuration in the About Dialog and the Welcome Page section on the Branding tab is not directly supported in Eclipse 4 RCP applications.
Using the Eclipse wizards you can create feature projects, similarly on how you create plug-in projects. An Eclipse feature project contains features.
A feature describes a list of plug-ins and other features which can be seen as a set of related components. It also has a name, a version number and in most cases a license information assigned to it.
A feature is described via a feature.xml file. The following listing shows an example of such a file.
<?xml version="1.0" encoding="UTF-8"?> <feature id="com.vogella.eclipse.featuretest.feature" label="Feature" version="1.0.0.qualifier" provider-name="vogella GmbH"> <description url="http://www.example.com/description"> [Enter Feature Description here.] </description> <copyright url="http://www.example.com/copyright"> [Enter Copyright Description here.] </copyright> <license url="http://www.example.com/license"> [Enter License Description here.] </license> <plugin id="com.vogella.eclipse.featuretest.feature" download-size="0" install-size="0" version="0.0.0" unpack="false"/> </feature>
The grouping of plug-ins into logical units makes it easier to handle a set of plug-ins. Instead of adding many individual plug-ins to your product configuration file, you can group them using features. That increases the visibility of your application structure.
Features can be used to install them into Eclipse applications and for the definition of Eclipse products. Features can also be used as basis to define a launch configuration.
Eclipse provides several predefined features, e.g., the
org.eclipse.e4.rcp for Eclipse RCP applications.
A product can either be based on plug-ins or on features. This setting is done on the Overview tab of the product configuration file.
On the Contents tab in the product editor you enter the plug-ins or features your products consists of.
A product does not perform automatic dependency resolution. If you add a feature to your product and want to add its dependencies, press the Add Required button.
You can create a new feature project via themenu entry.
If you open the feature.xml file you can change the feature properties via a special editor.
The Information tab allows you to enter a description and copyright related information for this feature.
The Included Plug-ins tab allows you to change the included plug-ins in the feature. If you want to add a plug-in to a feature, use this tab. A frequent error of new Eclipse developers is to add it to the Dependencies tab.
The Included Features tab allows you to include other features into this feature. Via the Dependencies tab you can define other features which must be present to use this feature.
The Build tab is used for the build process and should include the feature.xml file. The last two tabs give access to the configuration files in text format.
An Eclipse application needs to be exported (also called: deployed) to run outside of Eclipse. Exporting your product creates a folder with all required artifacts to run your application. This includes a native launcher specific to the platforms, e.g., Windows or Linux, you have exported it for.
Select your product configuration file to export your application.
Select the Overview tab and click on the Eclipse Product export wizard link.
In the wizard you can specify the target directory for the export via the
Directory property in the Destination group/section.
The export wizard is depicted in the following screenshot.
Root directory property can be used to specify a sub-folder in the destination which contains the complete exported application.
This is useful, if you export the product as an archive file.
The resulting directory can be shared with others, typically as an archive (zip) file. The export dialog allows you to create an archive file directl.
If the Generate p2 repository option is selected, an (p2) update site is generated in a repository folder. This folder can be used to update the Eclipse RCP application via the p2 API.
If you transfer the content of this directory to another machine (with the same architecture, e.g., Linux 64 bit), your application can start on this machine. Of course, the correct Java version must be installed on the target machine.
The artifacts which are included in an export are defined by the build.properties file of the plug-in. Eclipse provides an graphical editor for this file.
Eclipse adds the compiled Java classes by default. Other files must be added manually, e.g., icons or splash screen images.
An Eclipse application started from the Eclipse IDE has access to all resources available in the IDE. But to make them available in the exported application you need to select them in the build.properties file.
It is good practice to include new required resources immediately in the build.properties file. This avoids errors after the export of your application.
- Make sure the following items (if available) are included in each plug-in of the exported application
other static files, e.g., icons, splash.bmp, etc.
OSGi service definition files
The screenshot below shows the build.properties file for a plug-in with most of these components.
During the export or the start of the exported application you may encounter problems. If your application got successfully exported but cannot be started you find a log file ending with the .log extension in the configuration folder of your application. This file contains the error you encountered.
Alternatively the export process may fail. In both cases you can use this chapter as reference to try to find and fix the reason for the failure.
The most common problem is that the folder to which you export is not empty. If you export to a certain folder, ensure that the folder is empty. Exporting twice to the same folder may create file locks or results in error messages reporting version conflicts.
If the export encounters a problem please have a look into the following table for a solution:
Try using an empty target directory, sometimes the export cannot delete the existing files and therefore fails.
No executable file after the export
Check the flag "The product includes native launcher artifacts" in your .product file on the Overview tab.
Product could not be found
Validate that all dependencies are included in the product. Delete an existing launch configuration and restart the product from the IDE to see if everything is configured correctly.
Splash screen or other icons are missing
Check the build.properties file to see if all required images and icons are included in the export.
Splash screen is missing
Ensure that you have entered the defining plug-in in the "Splash" tab on the product configuration file. If this is not set, the splash screen is not displayed after the export. Unfortunately, it is displayed if you start the plug-in from the Eclipse IDE.
Issues during start of the application
Check the log file in the workspace folder of your exported application to see the error messages during the start process. Alternatively add the "-consoleLog" parameter to the ".ini" file in folder of the exported application.
applicationXMI argument is missing
Check the build.properties file to see if the Application.e4xmi and the plugin.xml files are included in the export.
Service could not be found or injected
Make sure that the bundle which provides the service has the
Activate this plug-in when one of its classes is
flag set. Also
Application ID could not be found
level of 1 and set auto-start to true for the
Translations not available in the exported product
Ensure via the build.properties file of the relevant plug-in that the files containing the translations are included in the export.
The delta pack contains the platform specific features and plug-ins which are required to build and export Eclipse applications for multiple platforms.
It also includes binary launchers for all platforms in the
See Wiki entry for Cross-platform builds for the usage.
You can also deploy your own RCP application bundled with a JRE
certain JRE is used. An Eclipse application first
installation directory for a folder called
and for a
If it finds one, then this JRE is used to
To include the JRE from your running environment, select the Bundle JRE for this environment with the product flag on the Launching tab of your product configuration file.
A headless build is an automatic build without user interaction and without a graphical user interface. It can be triggered from the command line. Typically, the build is automatically done via an additional software component called the build server which does so in a clean (and remote) environment.
Different solutions exist to do a headless build. Currently the most popular approach for building Eclipse RCP applications is based on Maven Tycho. Describing a headless build is beyond the scope of this description but you can see the online Maven Tycho tutorial for an introduction into headless builds for Eclipse RCP applications.
An example for a build server would be the Jenkins continuous integration (system). See the online Jenkins tutorial for an introduction into the setup, configuration and usage of Jenkins.
In newer Eclipse releases the manual product export does not always work.
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=525280 for a status.
The workaround is to setup a Maven Tycho command line build instead of using the user interface.
Use the product file export your Eclipse application.
Enter a new directory in the Directory field. If in doubt use the Browse button to find a valid directory. The following screenshot shows an example under Ubuntu.
Press the Finish button to start the export.
|The exported directory should be empty. If you export twice to the same directory, delete its content, otherwise the export fails with a dependency conflict.|
After the export finishes check the Root directory folder in the Directory folder.
A double-click on the native launcher starts your application. Ensure that you can start the application from your exported directory.
The Eclipse export wizards uses eclipse as default for your application launcher name, e.g., on MS Windows this results in an eclipse.exe launcher file.
Change this launcher name to myapp on the Launching tab of your product configuration file.
Export your application via the product file again and validate that the launcher name has changed.
Ensure that the target directory for the export is empty before the export.
Add a splash screen to your application. For this create or download a splash.bmp bitmap file.
Add the splash.bmp file to the main directory of your application. You can copy and paste it into the Package Explorer or Project Explorer view.
If you add files outside of the Eclipse IDE, you need to Refresh your project to see the file in Eclipse. This can be done via the F5 keybinding in the Package Explorer view.
The file name and the location of the file must be correct, otherwise Eclipse will not use your splash screen.
On the Splash tab of your product configuration file, define that your application plug-in contains the splash screen.
Start your application from the Eclipse IDE and verify that the splash is displayed.
Configure that the splash.bmp file is included into the exported application by adding it to the build.properties file of your application plug-in.
Export your product again and ensure that the splash screen is also shown if you start the exported application.
Make sure that the target directory of the export is empty before you start the export.
Create a new feature project called com.example.e4.feature via theentry. The following screenshot shows the first wizard page.
com.example.e4.rcp plug-in into the new feature.
com.example.e4.rcp plug-in open the
Select the Overview tab and ensure the `based on features options is selected.
Switch to the Contents tab in your product editor. Add the following features to your product via the Add… button.
Afterwards, press the Add Required button.
This adds the dependencies of the
org.eclipse.e4.rcp feature to the product.
Ensure that you have the four features from the screenshot included in your product.
Start your application via the product configuration file and ensure that the application starts correctly.
If the application does not start, check:
Copyright © 2012-2019 vogella GmbH. Free use of the software examples is granted under the terms of the Eclipse Public License 2.0. This tutorial is published under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Germany license.