Pascal,
Got it to work. Several issues were working against me, but a comparison of the
contents of the "shared" output between the director and my provisioning
service pointed me in the right direction.
The first step required that I copy the read-only installation's p2 directory
and files to a writable location, such as c:\MyRCPApp\runtime\shared\p2. Due to
Citrix's issues with files having *.profile extensions, a little renaming had
to be done, but that was small potatoes. The main thing was that my "shared"
directory needed to have a writable copy of my read-only installation's
profile. Otherwise, an InstallOperation would complain about broken
dependencies, even to simple bundles like org.eclipse.core.runtime.
The next part involved a config.ini change. I changed the eclipse.p2.data.area
property value to match the new, writable p2 location (as a URL):
file\:/c\:/MyRCPApp/runtime/shared/p2. I also added a new custom property
called myrcpapp.p2.shared and pointed it to the same location (as a URL):
file\:/c\:/MyRCPApp/runtime/shared/p2. The combination of these two values
would provide me with a file structure matching the output of the
org.eclipse.equinox.p2.director (that is, once I made some modifications to my
provisioning "service" logic):
c:\MyRCPApp\runtime\shared\p2
c:\MyRCPApp\runtime\shared\p2\features
c:\MyRCPApp\runtime\shared\p2\plugins
c:\MyRCPApp\runtime\shared\p2\org.eclipse.equinox.p2.core
c:\MyRCPApp\runtime\shared\p2\org.eclipse.equinox.p2.engine
c:\MyRCPApp\runtime\shared\p2\org.eclipse.equinox.p2.repository
... etc...
Next came the provisioning service changes. Instead of defining only an install
directory and a matching p2 directory, I also defined a "cache" directory. By
inspecting the p2 profiles output by the director, I discovered that the
org.eclipse.equinox.p2.installFolder property would need to specify the path to
my read-only installation's base directory, and the
org.eclipse.equinox.p2.cache would need to specify the path to my writable
"shared" directory. When provisioned in the past to a regularly installed,
writable installation, these two property values were always the same.
If the product were launched with a defined myrcpapp.p2.shared property value,
the cache directory would point to it. Otherwise, it would default to the
installation directory. Either way, the p2 directory would be based on the
cache value, which would point it to the writable p2 location. Now an
IProvisioningAgent could be created from an alternate p2 directory, which would
likewise obtain a default IProfile instance from the "shared" directory. For
example:
final File installDir = this.getInstallationDirectory(); // The
installed product directory
final File cacheDir = this.getCacheDirectory(installDir); // Either the
value provided by the myrcpapp.p2.shared property, or the install directory
final File p2Dir = this.getP2Directory(cacheDir); // A "p2"
directory under the installation directory or the shared directory
final IProvisioningAgent agent = this.createProvisioningAgent(p2Dir);
final IProfile profile = this.utils.getProfile(agent);
Later in the code, another method would prepare a profile registry based on the
IProvisioningAgent, the install directory, and the shared directory. I already
had code that called IProfileRegistry.setProfileStateProperties(Map), but the
Map specified org.eclipse.equinox.p2.installFolder and
org.eclipse.equinox.p2.cache as the same value. Now that they pointed to
separate locations, my InstallOperation would work.
Note: For some reason, I couldn't get the profile to be written without
creating a SimpleProfileRegistry and forcing it to lockProfile(Profile),
updateProfile(Profile), and unlockProfile(Profile). I know, they're restricted
internal classes, but I couldn't otherwise update the profile on disk.
After that, the InstallOperation was created, resolved, and launched with a
ProvisioningJob as expected. It took 6 days to figure out, but all's well that
ends well.
Thanks,
Chip
-----Original Message-----
From: Chip Downs <[email protected]>
To: p2-dev <[email protected]>
Sent: Tue, Apr 16, 2013 1:36 pm
Subject: Re: [p2-dev] Install features & bundles to separate location than RCP
product
Sure... and thanks for the reply.
I'm trying to add, update, and remove features/bundles from a base RCP
installation. The base RCP installation, which is located on a mounted drive,
is effectively read-only, including its configuration, features, plugins, and
p2 directories. I don't have any control over the installation since it's
streamed to the mounted location by a Citrix process in a virtual desktop.
I've already built a "provisioning" plug-in that uses the provisioning APIs to
install, uninstall, and update IUs at runtime via commands sent from a help
desk portal. For example, if a help desk agent specifies that User A is
authorized to use xyz.feature, the provisioning plug-in 1) receives an
installation command from the portal, 2) looks up the IProvisioningAgent, 3)
gets the default IProfile, 4) creates a ProvisioningSession, and 5) executes an
InstallationOperation. In a way, my base RCP app acts like an Apple O/S, except
that an external actor (the help desk) decides which "apps" (i.e.,
features/bundles) get installed and started. And that's the way my customer
wants the RCP app to behave: automated provisioning at runtime based on user
roles and identity.
If I start my RCP from a manually installed, writable location, it works just
fine. The bundles install and start as expected. Everything coded so far
assumes that the installation's configuration, p2, features, and plugins
directories can be modified. Naturally, running the same provisioning
operations against the read-only installation doesn't work.
At that point I started to explore whether the p2 and installed IUs could be
separated from the base RCP installation. The only thing I could find was the
-share option of the org.eclipse.equinox.p2.director. At least it showed me
that my IUs could be installed separately and still show up in the launched RCP
app. However, I'd obviously prefer NOT to execute a command from a separate
Java process if the same "share" logic could be executed through the
provisioning API instead.
I have a script that copies the base p2 directory to a readable location,
whereby I can install additional features/bundles via the
org.eclipse.equinox.p2.director. To do that, I specify a
eclipse.p2.data.area=c:\MyRCPApp\runtime\p2_citrix, set -destination as my base
RCP installation, and -share as c:\MyRCPApp\runtime\p2_citrix. After starting
the RCP app, the newly provisioned UIs appear show up properly in the plug-in
registry. Here's an example of the director command (which is executed from a
script via a Citrix process):
d:\Program
Files\Citrix\RadeCache\8eb777cc-3...\Scripts>c:\eclipse-3.7\eclipse.exe
-application org.eclipse.equinox.p2.director -repository
http://some-domain/repo -installIU my.test.thingy.feature.group -tag
TestInstall -destination d:\Program
Files\Citrix\RadeCache\8eb777cc-3...\Device\C\MyRCPApp -profile DefaultProfile
-shared c:\MyRCPApp\runtime\p2_citrix
Now, how might I use the provisioning API to do the same thing (at runtime)?
An IProvisioningAgent is based on a specific p2 URL. As it stands now, it just
grabs the DefaultProfile, which references the read-only installation. How
might I make it reference 2 different installations during an
InstallationOperation: one for the read-only installation and the other for the
installed IUs?
Thanks,
Chip
-----Original Message-----
From: Pascal Rapicault <[email protected]>
To: p2-dev <[email protected]>
Sent: Tue, Apr 16, 2013 12:22 pm
Subject: Re: [p2-dev] Install features & bundles to separate location than RCP
product
Hi,
When p2 is running in a shared install mode (which happens when eclipse is
installed in a read-only folder), the user can not cause an update of the base
(what is read only), so could you explain what it is you are trying to achieve?
Thx
Pascal
From: Chip Downs <[email protected]>
Subject: Re: [p2-dev] Install features & bundles to separate location than RCP
product
Date: 15 April, 2013 10:59:44 AM EDT
To: [email protected]
Reply-To: P2 developer discussions <[email protected]>
After experimentation using the director, I need to rephrase my question: What
is the equivalent way, if any, of specifying the -destination and -shared
values through the programmatic API (for an InstallationOperation) that would
otherwise be specified through a command-line execution of
org.eclipse.equinox.p2.director?
Anybody know?
Thanks,
Chip
-----Original Message-----
From: Chip Downs <[email protected]>
To: p2-dev <[email protected]>
Sent: Fri, Apr 12, 2013 12:03 pm
Subject: Install features & bundles to separate location than RCP product
Hi,
I have an RCP product that installs and uninstalls features/bundles just fine
when running from a traditional, Eclipse-like installation. Using logic similar
to the following article, it headlessly performs updates from a repo site,
modifies the product's "p2", "features", and "plugins" directories accordingly,
and starts the installed bundles (as applicable):
http://wiki.eclipse.org/Equinox/p2/Adding_Self-Update_to_an_RCP_Application#Headless_Updating_on_Startup
The problem is that the product also needs to perform the provisioning
operations from a read-only installation on a shared network folder. For many
of its users, the installed product doesn't have the luxury of writing to its
"p2", "features", and "plugins" directories.
Handling the p2 directory seems easy enough. All I need is a script that copies
the p2 directory from the read-only installation to a writable local path and
specifies the new location via eclipse.p2.data.area property.
The other directories are a different issue, however. Install operations fail
because they're trying to write to the read-only installation's features and
plugins directories. I can't seem to find another configuration property to
specify an alternate location for the installed features and plugins. Although
a number of articles and blogs entries about shared locations and bundle
pooling seemed promising, they appeared to deal with the command-line director
application.
Again, my product's installations are performed programmically via
InstallOperations and ProvisioningJobs in conjunction with the simple
configurator. I'd think that there were some simple configuration property to
point them at an alternate installation path. I certainly hope that it doesn't
require Java code changes and/or a different product build.
Thanks!
Chip
P.S. This problem appears to be similar to the one described here:
http://stackoverflow.com/questions/11666907/p2-self-provisioning-rcp-vs-windows-uac
_______________________________________________
p2-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
2-dev mailing list
[email protected]
ttps://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
2-dev mailing list
[email protected]
ttps://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/p2-dev
