Feeds:
Posts
Comments

Posts Tagged ‘p2’

Recently I ran in to an interesting little problem with “resolution:=optional” OSGi directive. Basically what “resolution:=optional” says is that the even though the package imported with this directive is not present in the system  bundle would be resolved at run time. This is logical in case of compile time dependencies of the bundle not being needed at runtime. Or is it?..

I had to ponder a little while before putting down that last statement until I got how it can be so. Usually bundle needs compile time dependencies at run time as well to function correctly. But what if we have an execution path which never gets called at runtime inside our bundle. If that execution path contains imports then these import dependencies will not be needed at run time.

Typically Maven Bundle Plugin is used to incorporate bundle creation at build time. So in this case the general practice I used to follow was to explicitly import obvious dependencies and use a “resolution:=optional” directive with “*” wild card as a catch all mechanism for all other imports. Even if we include some imports which are not needed at runtime we can get away with optional directive since bundle will resolve without them, right?

This is all good and rosy until p2 come in to the picture. Apparently p2 installs bundles exporting optional imports too if it can find them during provisioning. So you end up installing bundles that may  not required at runtime along side the feature. Though generally not disastrous this is a concern if you want to keep your feature installation lean.

In my case the issue was some unwanted bundle getting mysteriously installed with my feature even though it’s packages are not explicitly imported in any of bundle’s sources. As it turned out I had included a dependency required for tests without specifying it should be in the test scope. So naturally with “*;resolution:=optional” in place the Bundle Plugin dutifully did it job by placing an import in the manifest which led to this particular bundle installation at provisioning time.

Solution was trivial. Place the dependency in test scope and Bundle Plugin did not include an import since test scoped dependencies will not be imported in the manifest at all. Alternatively I could have explicitly unimported the offending packages or make requires.greedy instruction false at feature p2.inf to stop P2  greedily installing optional dependencies [1] though these solutions are hacky which do not deal with the root cause directly in my case. But it’s always to good to have alternatives isn’t it?. :).

[1] http://ekkescorner.wordpress.com/2010/04/26/p2-is-my-friend-again/

Read Full Post »

An earlier post dealt with how a file can be copied to a product during a feature installation during a p2 provisioning action. This post expands on that. Although natives touchpoint has got a copy instruction it only works with files. But it has got an unzip instruction which can be used to unzip a zip file to a given target at feature installation time. So we can workaround the limitation of copy instruction using unzip by having a zip file of the folder to be copied inside the feature.

Following is a sample p2.inf configuration to unzip a folder called configFolder to configurations directory in the product.

instructions.configure = \

org.eclipse.equinox.p2.touchpoint.natives.unzip(source:${installFolder}/

configFolder.zip,target:${installFolder}/configurations);

Read Full Post »

This post will describe how to install additional files such as configuration files, licenses etc. to a product along with a equinox feature installation. The files of interest is described below.

1. p2.inf

This file can be used to declare provisioning actions. More information about p2.inf format can be found at [1].  Various installation actions can be done by using touchpoints. A touchpoint presents an interface between p2 and a particular runtime configuration. Currently there are two touchpoints which contain instructions to performed, org.eclipse.equinox.p2.touchpoint.natives (os level instructions) and org.eclipse.equinox.p2.touchpoint.eclipse (p2 level instructions). Instructions fall in to one of the phases “install”, “uninstall”, “configure”, “unconfigure” in the p2 engine phases. Many of these instructions accept arguments.
Comprehensive documentation about touchpoints can be found at [2].

For this discussion we use natives touchpoint’s copy instruction. There is a particular syntax that has to be followed when specifying a instruction.

Citing from documentation..

 As an example – an “install” instruction for a bundle might consist of the following statement:

installBundle(bundle:${artifact});

* installBundle is the action name
* bundle is the parameter name
* ${artifact} is the parameter value. The value ${artifact} signifies the use of a pre-defined variable named “artifact”.

Now let’s specify we need to copy conf.xml file to configuration folder upon feature installation.

instructions.configure =  \ org.eclipse.equinox.p2.touchpoint.natives.copy(source:${installFolder}/

conf.xml,target:${installFolder}/configuration/conf.xml,overwrite:true);

Here we have specified this instruction should be carried out in “configure” phase using instructions.configure directive. ${installFolder} is one of the predefined variables defined in all the phases which denotes the root folder for current profile.

2. build.properties

The role of the build.properties file is to map development-time structures in a bundle’s project onto the structures described in the bundle’s manifest and needed at runtime. It’s documentation can be found at [3]. In this case we configure it to copy our configuration file to the generated feature during feature build. Important thing to note is that build.properties file is used at build time while p2.inf is used at feature installation time to perform similar jobs.

We use a feature specific property root to indicate to list the files and folders to be copied to the root of the generated artifacts. Documentation about rootfiles can be found at [4].

Here are the entries in the build.properties used in this example.

custom=true
root=file:conf.xml

From documentation..

‘custom=true’  – indicates that the build script is hand-crafted as opposed to automatically generated. Therefore no other value is consulted.

“file:” prefix is used to denote a relative path while “absolute:” prefix is used to denote an absolute path. Relative paths are taken relative to the containing feature.

With these configurations in place we are ready to build the feature and provision it in to the respective profile.

[1] http://wiki.eclipse.org/Equinox/p2/Customizing_Metadata

[2] http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.platform.doc.isv/guide/p2_actions_touchpoints.html

[3] http://help.eclipse.org/helios/topic/org.eclipse.pde.doc.user/reference/pde_feature_generating_build.htm

[4] http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.pde.doc.user/tasks/pde_rootfiles.htm

Read Full Post »