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.
HTH
>
> Thanks!
>
> 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).
>>>
>>> B) Misconfiguration
>>> 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))
>>>
>>> HTH
>>>
>>> On 2010-12-04, at 1:21 AM, Kevin McIntire wrote:
>>>
>>>> Hi,
>>>>
>>>> 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,
>>>> monitor);
>>>> engine.perform(plan, monitor);
>>>> this.configurator.applyConfiguration();
>>>>
>>>> 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.
>>>>
>>>> Thanks,
>>>>
>>>> Kevin
>>>> _______________________________________________
>>>> p2-dev mailing list
>>>> [email protected]
>>>> https://dev.eclipse.org/mailman/listinfo/p2-dev
>>>
>>
>> _______________________________________________
>> p2-dev mailing list
>> [email protected]
>> https://dev.eclipse.org/mailman/listinfo/p2-dev
>
> _______________________________________________
> p2-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/p2-dev
