Re: [p2-dev] Follow up: Updating to a certain version

[Thomas Kratz <eiswind@xxxxxxxxxxxxxx>]

Hi Susan,

first thanks for the input on this. I'll get to Elenas example on the weekend.
I did however use the files exactly as I checked them out from cvs, only added a try/catch and some log statements in p2util. It seemed to work within the ide, but when I built it an tried the deployed version it failed. ds was there, checked that, I had to manually start the p2.engine to make it work. 

However in the meantime I started of to transfer that to my own product and I'm very happy that the api goes final now.
If i can provide any further input let me know.

Regards 
Thomas

2010/5/18 Susan Franklin McCourt <susan_franklin@xxxxxxxxxx>

Hi, Thomas. Just catching up from the weekend's questions. It sounds like Elena has given you a good example, but just to follow up with some of your observations/questions.

The problem you observed with not having the p2 services registers sounds most likely as if the declarative services bundle was not present and/or started in your product. Were you using the .product file and releng file from this example? There is some discussion on this issue in a previous thread on the equinox mailing list. [1]. If you did have declarative services (org.eclipse.equinox.ds) included and started in your product, and still had a problem, I would be very interested in knowing about it.

You properly concluded that the org.eclipse.equinox.p2.ui.Policy class is only used to drive the UI. Those queries controls what appears in the installed software page and in the available software page on the install wizard. The idea of the Policy class is that the p2 UI can be reused with a few tweaks that are done via Policy. The documentation for all of this appears here [2]. However, I know that parts of the cloud example doc are out of date due to recent changes [3] and I plan to update this doc now that things are settling down. [4]

Elena is right about creating your own profile change request and provisioning plan when you have very specific needs for updating. The UpdateOperation is really an abstraction intended for the very common cases. In general, using the basic constructor will search for updates to all install roots in all known repositories. If you wanted to check a server version before even deciding to update, you would want to do that before creating the operation, and at that point, you would know which IU you want to install. You could still pass this IU to UpdateOperation, and it would assemble the profile change request for you, but as Elena points out, at that point in time you have all the info needed to use the lower level API.

susan

[1] http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg06177.html
[2] http://wiki.eclipse.org/Equinox/p2/Adding_Self-Update_to_an_RCP_Application
[3 ]https://bugs.eclipse.org/bugs/show_bug.cgi?id=290973
[4] https://bugs.eclipse.org/bugs/show_bug.cgi?id=278884


Thomas Kratz ---05/17/2010 01:24:46 AM---Hi all,

Thomas Kratz <eiswind@xxxxxxxxxxxxxx> Sent by: p2-dev-bounces@xxxxxxxxxxx 05/17/2010 01:24 AM Please respond to P2 developer discussions

To: p2-dev <p2-dev@xxxxxxxxxxx> cc: Subject: [p2-dev] Follow up: Updating to a certain version

Hi all,

I've been having a tough time with p2, but most of the trouble where caused by myself. Thanks for the help so far, at leat I have the UI up now and thanks to finding out that p2.data.area=@config/../p2 I now know that this wont work when you change the osgi.configuration.area. Really had a fight with this.

But I still need your help with understanding the API. I want to to a headless Update on Startup, and I looked into the prestartupade and the cloud example. As far as I can see the Policy in the cloud example is useful only to the p2 UI.

What I need to achieve is that I only update to a certain osgi version, because client and server need to stay in sync and I cannot know when the server gets updated. So the client asks the server for its version at startup (simply policy, versions have to match) and then I want to update to the same version on the client side. I did some diving into the API but I didn't see any starting point where to place such a restriction on the UpdateOperation. I can see the available Updates after the resolve, but looking at the "Update" I don't understand how I should select the right one because there so little info exposed in there.

If you could give me a starting point, wether to place a query upfront the resolve operation or wether to select the right update afterwards this would be of great help to me.

If I need to give any further information please let me know.

Regards Thomas

_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev

_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev

-- 
http://www.buchmanager.com
http://thomaskratz.blogspot.com
http://twitter.com/thomas_kratz