[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [p2-dev] what is "org.eclipse.equinox.p2.type.lock"
- From: Jacek Pospychała <jacek.pospychala@xxxxxxxxx>
- Date: Fri, 25 Mar 2011 14:55:45 +0100
- Delivered-to: firstname.lastname@example.org
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=cHa/bo/9m8+K9GjxChm+kxxhmO4FwMkykfdVzcrJCzBPJOXRlT9W8UkSwfA7AIxxSu jOT9F/LLQ936KFhy3gItrcVrD7X/2UuSuFAn8uXkqdCFaewwTYJuQvlC4LcClusCXbwC OmCrooeJb+jypuZlmi22Q2/I40E4gDrn5hARE=
ok, I'm a bit closer to the problem.
it's related toÂeclipse.p2.data.area property in configuration/config.ini
Initially, when product is first installed, eclipse.p2.data.area points to absolute path in product main install dir, e.g. "file\:/Applications/Abc/eclipse/p2"
At this time, everything seems possible to update and remove, at least from p2 UI.
After any provisioning operation, the eclipse.p2.data.area get's replaced with relative path "@config/../p2"
Now on next product run, a new p2 folder is created next to cascaded configuration area - somewhere in user directory. (Although this folder never existed before)
From now on, nothing seems possible to update or uninstall from p2 UI.
Now if I create a symbolic link from cascaded/p2 to /Applcations/Abc/eclipse/p2 all is updateable again.
So If I'm getting this correctly, p2 convertsÂeclipse.p2.data.areaÂabsolute path to relative path with "@config" and then resolves "@config" variable to cascaded directory, instead of main directory.
2011/3/22 Jacek PospychaÅa <jacek.pospychala@xxxxxxxxx>
I'm trying to understand what is this property "org.eclipse.equinox.p2.type.lock", who sets it and why.
Basically, there's a Mac product with extreemly confusing configuration. It uses cascaded configuration areas,Â
a shared bundle pool and another one in user directory. It has some top level features that are not updateable (no matter if I'm root or regular user).
At the top of that product, I'm installing my feature. Unfortunately, after installing it, I can't update it due to "updates are not permitted" error.
So far, I found that this is caused by org.eclipse.equinox.p2.type.lock property set to 3 for my feature IU in profile metadata.
If I replace property with 1, then update goes one step further and fails somewhere else. (yay!)
So I'm wondering if anybody knows how does p2 decide to set the lock property on newly installed feature.
Is there any documentation for that, or is there any good place to set a breakpoint? e.g. during the installation or during first start?
Thanks in advance!