| How to validate an upgrade before installation [message #933748] |
Fri, 05 October 2012 05:56  |
Eclipse User |
|
|
|
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 at the help But I don't understan where to pu the code or config so that my code get executed. Is it in the feature.xml?
Lastly:
Is there an example how to create and use p2 touchPonts?
[Updated on: Fri, 05 October 2012 08:28] by Moderator |
|
|
|
|
| Re: How to validate an upgrade before installation [message #986125 is a reply to message #983332] |
Mon, 19 November 2012 00:27  |
| Eclipse User |
|
|
|
Martin,
I followed the steps from StackOverflow link
(http://stackoverflow.com/questions/6154367/a-working-example-of-custom-p2-provisioning-action)
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 (instructions.install) but
maybe configure phase could work too. Collect phase did not work. I put
it in p2.inf in my feature.
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 host plugin. So the install
works like this:
* Actions plugin is downloaded
* My action is executed
* The action detects whether my host plugin is already installed and if
yes, it calls into it to retrieve licensing info. The host plugin has to
expose an API for the action. Action checks host 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 must be versioned. 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 with action code can be fixed and update/install retried.
* Actions API changed between Eclipse 3.5 and 3.6. I will probably drop
support for 3.5 as it's pretty old anyway.
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.
I hope this helps you.
Best regards,
Peter
|
|
|
Powered by
FUDForum. Page generated in 0.45351 seconds
Home