Eclipse p2 alternative for custom install handlers

Question

Before p2, one could write a custom install handler with a feature that was executed to do any 'custom' task during installation.

I see that with p2 the custom install handler is no longer supported. I keep hearing about 'custom touchpoints' being the replacement for that.

However I cant find any concrete example/documentation for it.

Can anyone tell me how to get the functionality of custom install handlers with the p2 update manager.

Edit: A description of what I want to do -

I need to edit the eclipse.ini file and set the -Xmx property to a value based on whether we are running inside a 64 bit or 32 bit env.

Edit 2: I tried creating a p2.inf file in my feature with the following line -

instructions.install = \
addJvmArg(jvmArg:-Xmx900m);

instructions.install.import= \
org.eclipse.equinox.p2.touchpoint.eclipse.addJvmArg,

and it works, however it does not differentiate between 32 and 64 bit.

Answer 1

p2.inf definitely is the right place to perform customized actions. It is a good place to add vm arguments into .ini. You could put a p2.inf under your feature/plug-in.

Updated on 20 Dec.:

I tried it on my own environment, it works well to set different vm args when installing the same feature on linux 32bit and 64bit. You could download the example code to play with it.

#create a requirement on the IU fragment we are creating
requires.2.namespace=org.eclipse.equinox.p2.iu
requires.2.name=configure.com.example.yourfeature.linux.x86
requires.2.range=[1.0.0,1.0.0]
requires.2.greedy=true
requires.2.filter=(&(osgi.os=linux)(osgi.arch=x86))

#create a IU frament named configure.com.example.yourfeature.linux.x86 for linux 32 bit
units.0.id=configure.com.example.yourfeature.linux.x86
units.0.version=1.0.0
units.0.filter=(&(osgi.os=linux)(osgi.arch=x86))
units.0.provides.1.namespace=org.eclipse.equinox.p2.iu
units.0.provides.1.name=configure.com.example.yourfeature.linux.x86
units.0.provides.1.version=1.0.0
units.0.instructions.configure=addJvmArg(jvmArg:-Xmx500m);
units.0.instructions.configure.import=org.eclipse.equinox.p2.touchpoint.eclipse.addJvmArg,

#create a requirement on the IU fragment we are creating
requires.3.namespace=org.eclipse.equinox.p2.iu
requires.3.name=configure.com.example.yourfeature.linux.x86_64
requires.3.range=[1.0.0,1.0.0]
requires.3.greedy=true
requires.3.filter=(&(osgi.os=linux)(osgi.arch=x86_64))

#create a IU frament named configure.com.example.yourfeature.linux.x86_64 for linux 64 bit
units.1.id=configure.com.example.yourfeature.linux.x86_64
units.1.version=1.0.0
units.1.filter=(&(osgi.os=linux)(osgi.arch=x86_64))
units.1.provides.1.namespace=org.eclipse.equinox.p2.iu
units.1.provides.1.name=configure.com.example.yourfeature.linux.x86_64
units.1.provides.1.version=1.0.0
units.1.instructions.configure=org.eclipse.equinox.p2.touchpoint.eclipse.addJvmArg(jvmArg:-Xmx900m);

Answer 2

I think the most complete docs on the matter is the Eclipse wiki. You're probably interested in "native touchpoint actions", but it is also possible to implement your own touchpoint action, i.e. a Java class which is invoked as part of the installation process.

EDIT: Customizing Metadata contains some info on what you can put in the p2.inf file. The example given there is:

 instructions.install = \
    ln(targetDir:@artifact,linkTarget:foo/lib.1.so,linkName:lib.so);\
    chmod(targetDir:@artifact,targetFile:lib/lib.so,permissions:755);
 instructions.install.import= \
    org.eclipse.equinox.p2.touchpoint.natives.ln,\
    org.eclipse.equinox.p2.touchpoint.natives.chmod

Answer 3

There are two articles that explain how to achieve this:

• How to Add Custom Install Actions to Your Next Eclipse IDE Plug-in
• Custom touchpoints in P2

First one covers a bit more options, second is only about P2 touchpoints.

WARNING: when we added custom touchpoints to our plugin, it started deadlocking (quite often, but not always) at install time (we did not want the risk and removed them). Maybe we did something wrong but this is something to be aware of.

Built-in touchpoints seem to work fine, though.