Showing posts with label P2. Show all posts
Showing posts with label P2. Show all posts

Thursday, May 13, 2010

Features for Multi-OS Plugins

Assume you have a plugin for more than one, but not all platforms. One that may run on Windows and Linux, but not OS X. Assume it's called the "non_osx_tool" plugin, and the plugin's MANIFEST.MF contains a filter:

Eclipse-PlatformFilter: (| (osgi.os=linux) (osgi.os=win32))

Fine.

Now you switch to P2, and base your Product on Features. So there's a feature that lists this plugin. If you just list the plugin, then try to compile for all OS, all will look OK, but installation will fail on OS X because the feature requires the installation of the "non_osx_tool" plugin, which in turn declares itself unavailable for OS X.

You can specify in feature.xml that a plugin is OS-specific:

<plugin id="non_osx_tool" os="linux" ...

That way, the installation will work better because the feature will only trigger installation of the non_osx_tool on Linux. But you can only list one OS, Linux or Windows, not both.
I tried to use os="linux,win32" but that resulted in compiler errors The type ... cannot be resolved. It is indirectly referenced from required .class files referring to code in dependent plugins which were suddenly not found. Listing multiple architectures is either unsupported, or uses a format that I couldn't find.

Solution:
Create additional features "my_feature.win32" and "my_feature.linux". They each list the plugin for only win32 or linux, and the top-level feature then includes both these sub-features with a filter:

<includes
id="my_feature.linux"
version="0.0.0"
os="linux"/>
<includes
id="my_feature.win32"
version="0.0.0"
os="win32"/>

Friday, May 7, 2010

Product Editor Bug

When switching to P2 and changing from plugin-based to a feature-based product, the application suddenly refused to start because of problems in the config.ini.

Traced down to misleading product editor, https://bugs.eclipse.org/bugs/show_bug.cgi?id=312086

Default Eclipse Workspace via config.ini

By default, the workspace of an RCP app is somewhere inside the install location, and might actually differ for Linux, Windows, OS X or different Eclipse releases.
I needed a location in the user home directory, independent from the OS, and not affected by updates (including complete replacement) of my RCP application.
The solution is adding something like this to the RCP's config.ini:

# Set default workspace location
osgi.instance.area.default=@user.home/MyRCPAppWorkspace

In the *.product file editor, the Configuration section allows you to specify a custom config.ini to accomplish this, but that brought up another problem: The original content of the config.ini beyond my workspace location settings, entries like osgi.framework=file\:plugins/org.eclipse.osgi_3.5.2.R35x_v20100126.jar, changes with Eclipse releases, so you have to continually update your custom config.ini?

Solution with P2: Use the auto-generated config.ini, and instruct P2 to add your custom content by adding a file p2.inf to your product with the following content:

# Add the following to the generated config.ini
instructions.install = \
setProgramProperty(propName:osgi.instance.area.default,propValue:@user.home/MyRCPAppWorkspace);

Tuesday, May 4, 2010

Learning Eclipse P2

Good intros: http://www.vogella.de/articles/EclipseP2Update/article.html ,
http://www.slideshare.net/irbull/p2-introduction.

Exporting a feature with P2 info from the IDE is quite straight forward.

When adding the P2 UI to the final product by adding the feature org.eclipse.equinox.p2.user.ui, I had strange problems under Eclipse 3.5.2:
Product wouldn't start, or not include the P2 UI, or not have much P2 information.
It only works halfway from within the IDE, and only after the run-configuration is deleted and re-created.

To export a working product:
Include org.eclipse.equinox.p2.user.ui with either the full version number, or use 0.0.0, but beware that this must be entered manually because of https://bugs.eclipse.org/bugs/show_bug.cgi?id=279480

This will provide a product with the P2 GUI, but About/Installation Details would be nearly empty, Configuration completely blank unless also exporting with metadata.
Checking the "metadata" option on export combined with source export, however, results in error "gather.sources" does not exist because of bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=286940.
Export with meta data but without sources works OK.

Info about plugins/features in general, based on the old update mechanism: http://www.eclipse.org/articles/article.php?file=Article-Update/index.html Includes tip to always end the update site link with "/"!

Merging repositories, for example a repository resulting from a new stable version into the 'main' repository on a web site:

Remaining issue:
  • OK to export product, based on features, into repository
  • OK to export additional feature into repository, then install into product via UI
  • OK to export update for that additional feature, and update product via UI
What doesn't seem to be possible:
  • Export update for feature in product to repository. Update fails with message regarding conflict between the new plugin from the updated feature and the original plugin that the product requires
Workaround: Always update the whole product, including version of the whole product, then the old product can update itself.