On 2010-12-10, at 6:19 PM, Kevin McIntire wrote:
We are still working on resolving the issue - I think it is being caused by the org.eclipse.equinox.simpleconfigurator.manipulator issue not being in our agent, which itself appears to be tied to the fact that we are running our provisioning agent as a run profile in eclipse rather than deploying a feature to a container, which is in turn caused by the fact that we are ecplise and osgi n00bs in addition to knowing very little about p2.
If you are running self hosted (starting OSGi from within eclipse0 you will unlikely be able to get that working.
On another note, we are confused about how profiles interact with installations. Is there any chance that the fact that we are installing into a "custom" profile is what is preventing us from seeing the bundle/feature in the console? We can see the feature installed on the file system under the profile data location, and querying p2 for the bundle also shows that bundle as "installed", but doing an ss/services/apps/etc from the console shell does not show the bundle at all. In fact, we see similar behaviour when installing via provinstall, although, again, that may be due to misconfiguration as well.
A profile contains the p2 point of view on the system. It is a description in terms of IU of all the things that constitute your install. In the profile registry, the most recent profile represents what is currently running. When a profile is being modified the profile registry is locked. Upon the successful completion of the modification (note that modification to the profiles can only done through the engine), a new profile is being persisted on disk thus capturing the new state your system is in.
How / when / who actually do the changes on the file system. This is done by a collaboration between: the engine, the touchpoints and the touchpoint actions who are "executing" the touchpoint instructions that are mentioned in the IUs.
Given a bunch of IUs to install / uninstall / update, the engine will look at the touchpoint instructions that are listed in each IU, find which touchpoint or action is responsible for the execution of this instruction and invoke the instruction.
When it comes to configure an OSGi system and eclipse, this is covered by the eclipse touchpoint (bundle org.eclipse.equinox.p2.touchpoint.eclipse) which will know what it means to "install a bundle", "set a start level", "set a property", etc.
Another thing to remember is that in order to maximize reusability of the IUs, a producer of an IU will rarely (see never) specify its start level and details like these. Instead this information is left to be produced by the consumer of a bundle (e.g. in eclipse the top level product) who creates a InstallableUnitFragment (also referred to as CU). This InstallableUnitFragment (which will be attached to an IU by the resolver), is responsible for providing the touchpoint instructions that will be executed.
All that said :), if you are trying that out from within eclipse it is likely why you are not necessarily encountering success. If you can share a simple setup (projects, launch configs, etc.) then I can try to see by myself.
On Dec 4, 2010, at 6:49 PM, Pascal Rapicault wrote:
Forgot to mention, you may be interested in taking a look at the equinox.p2.operations API (http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/api/org/eclipse/equinox/p2/operations/package-summary.html
It encapsulates behind a few lines of code the same thing than you have in your code.
On 2010-12-04, at 4:44 PM, Pascal Rapicault wrote:
This code looks correct. I can think of several problems:
A) Be sure that there is an IU fragment associated with all the IUs representing the bundles. This IU fragment also referred to as "configuration unit" is supposed to say that the bundles needs to be installed and at which start level. You can see if an IUFragment is attached on an IU by introspecting the plan. For example in the eclipse SDK we ship a CU called tooling.osgi.bundle.default that configures all bundles to be installed and started at start level 4, and then individual CUs that configure bundles with specific values (e.g. toolingcocoa.macosx.x86_64org.eclipse.equinox.simpleconfigurator).
1) the agent running the provisioning operation does not contain org.eclipse.equinox.simpleconfigurator.manipulator and therefore the bundles.info
file does not get written.
2) the system being provisioned does not contain org.eclipse.equinox.simpleconfigurator, therefore the creation of the bundles.info
is not done.
In both cases, the values would end up being written in the config.ini, but since there is no Configurator service registered for the config.ini (the only Configurator service being registered is done for SimpleConfigurator) then the call is a noop.
C) If this does not help then you will have to resort to see what happens when the EquinoxManipulator persists the changes (EquinoxManipulatorImpl.save(boolean))
On 2010-12-04, at 1:21 AM, Kevin McIntire wrote:
We are looking at using P2 as part of a continuous deployment infrastructure to support a high volume distributed service and wanted to see if we could get a little assistance in bringing up a prototype using p2 as a provisioning agent in headless containers. Specifically, we've looked at the p2 source code and at the toast example, and are having an issue where we install a feature via (roughly)
IProfileChangeRequest request = planner.createChangeRequest(profile);
ProvisioningContext context = new ProvisioningContext(agent);
IProvisioningPlan plan = planner.getProvisioningPlan(request, context,
The condition we observe is that the operation above succeeds, and we can query the IU out of the profile, but cannot see it (via ss) on the equinox console (we are just deploying to a debug container from eclipse) and we cannot see the bundle in any other way from the console. Does anyone know what we are missing to "commit" the install?
My apologies if this if off topic or on the incorrect list.
p2-dev mailing list
p2-dev mailing list
p2-dev mailing list