Question

We have an eclipse feature that is licensed and the license is handled by our own code. The user can go in on our update-site and upgrade his feature. The problem we face is when the user’s license needs to be updated before he can use the new upgrade.

What I want to do is to validate the feature version against the users license and warn the user that his license needs to be updated before he install.

I thought I would do this using a custom eclipse p2 touchPoint action validateLicense.

Example:

My code is called, where I validate the version against the user’s license. If it fails I warn the user and he can then cancel the installation.

So my first question is:

• Do I get this right, or is it some other way to do this?

My second question is pretty basic:

• Where do I tell eclipse to run my code?
  I have looked here at eclipse help where they explain what it is. But I don’t understand where to put the information to run my code? Is it in the feature.xml.

Lastly:

• Is there an example how to create and use p2 touchPonts?

Answer 1

I implemented a custom action as shown here and I have a system that seems to work. I left out “touchpoint” extension as it’s unnecessary in my case, but the rest is the same.

My action is executed during install phase of my feature (instructions.install) but maybe configure phase could work too. Collect phase did not work.

The action is executed during installation process, after the download was already performed. Ideally it would be before the download but it’s not a big issue for me. Returning an error status from the action cancels the install. It leaves some downloaded files around but they do not get activated and are probably removed later by p2’s garbage collector.

I also managed to do some more interesting things. My actions plugin has a dependency (optional and non-greedy) on my main plugin. So the install works like this:

• Actions plugin is downloaded
• Custom action is executed
• The action detects whether my main plugin is already installed and if yes, it calls into it to retrieve licensing info. The main plugin has to expose an API for the action. The action also checks main plugin’s version to detect whether the API is there or not.
• The action now can decide whether to proceed or cancel the install. It can even interact with the user using Display#syncExec (this is what the code in checkTrust phase does so I think it’s safe). If needed, the action could also detect whether the install is headless.

Some gotchas:

• Action itself must be versioned. It’s the version you declare in plugin.xml and p2.inf files and it’s different from plugin’s version. I just replace 1.0.0 with the same version my plugin has. This way the latest version of the action plugin is always downloaded before being executed. This is great because now any problem changes to licensing rules can be implemented in actions plugin.
• Actions API changed between Eclipse 3.5 and 3.6. I will probably drop support for 3.5 as it’s pretty old anyway.
• Actions plugin should probably be signed. It’s the case in my case. The system seems almost too powerful to me as just pointing Eclipse to an update site gets it to execute downloaded code.

I still need to test how this works with different versions of Eclipse and other IDEs. I saw a strange (non-blocking) error with 3.6. However the results are promising and it looks like the system might actually work.