Recently I came across touchpoint instructions functionality I wasn't aware of.
It's the .import syntax. This is used with p2.inf files in the following way
"instructions.<phase>.import = <qualified action name> [,<qualified action
name>]*".
Does this mean that instead of
<instruction key='install'>
installOsgiConfig(configuration:${iu})
</instruction>
I can have IU with touchpoint instructions
<instruction key='install.import'>
org.eclipse.virgo.kernel.deployer.p2.touchpoint.installOsgiConfig
(configuration:${iu})
</instruction>
?
I guess in this case my contributed action won't be requalified by the
EclipseTouchpoint as described below.
Is this the expected usage of the .import syntax?
Thanks,
Bobby
From: [email protected] [mailto:[email protected]] On Behalf
Of Kapukaranov, Borislav
Sent: Tuesday, August 30, 2011 8:00 PM
To: P2 developer discussions
Subject: Re: [p2-dev] touchpoints and manipulators
Hey,
I investigated the issue a bit more. Since the action was contributed to
EclipseTouchpoint it was qualified by its "qualifyAction(String actionId)"
method which adds org.eclipse.equinox.p2.touchpoint.eclipse (=Activator.ID) in
front of the actionId.
Meanwhile my action was added to the actionMap with the following key:
org.eclipse.virgo.kernel.deployer.p2.touchpoint.installOsgiConfig, therefore
the error.
The qualifier for my action is defined by the namespace identifier of the
contributing extension as can be seen in ActionManager.getActionMap():
if (actionId.indexOf('.') == -1)
actionId = actionElement.getNamespaceIdentifier() + "." + actionId;
//$NON-NLS-1$
This is why my action was registered with qualifier that later can't be
discovered.
Basically this means I need to have a bundle with the same symbolic name as
touchpoint.eclipse, if I got it right.
Do you have any suggestions on how can I proceed? If there are better options
than contributing the action or if I can configure my way through that I'm all
ears :)
Thanks,
Bobby
From: [email protected] [mailto:[email protected]] On Behalf
Of Pascal Rapicault
Sent: Friday, August 26, 2011 3:33 AM
To: P2 developer discussions
Subject: Re: [p2-dev] touchpoints and manipulators
Hey Boris,
Would you be able to provide a simple action that I could use to diagnose. Thx.
I was just thinking that we could declare new actions and the dependencies
would be injected using DS. Unfortunately I don't think this can be made to
work since each the TP that needs to be injected in the action needs to be
contextualized to the running provisioning operation. We have to remember that
p2 can manipulate multiple profiles at the same time (e.g. when installing into
self, or while exporting an app from PDE) and that the having mix and match
would just be very bad.
PaScaL
On 2011-08-12, at 1:53 PM, Kapukaranov, Borislav wrote:
I just tried the action contribution. It seems it isn't working but I may be
doing something wrong...
Here is a regular tpuchpoint.eclipse action:
<extension
point="org.eclipse.equinox.p2.engine.actions">
<action
class="org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.AddProgramArgumentAction"
name="addProgramArg"
touchpointType="org.eclipse.equinox.p2.osgi"
touchpointVersion="1.0.0"
version="1.0.0">
</action>
</extension>
And this is my action:
<extension point="org.eclipse.equinox.p2.engine.actions">
<action
class="org.eclipse.virgo.kernel.deployer.p2.touchpoint.actions.ConfigurationInstallAction"
name="installOsgiConfig"
touchpointType="org.eclipse.equinox.p2.osgi"
touchpointVersion="1.0.0"
version="1.0.0">
</action>
</extension>
Even though they look alike the engine didn't like it - the execution of a
provisioning plan with iu that requires my action fails with:
Status ERROR: org.eclipse.equinox.p2.engine code=0 No action found for:
org.eclipse.equinox.p2.touchpoint.eclipse.installOsgiConfig.
java.lang.IllegalArgumentException: No action found for:
org.eclipse.equinox.p2.touchpoint.eclipse.installOsgiConfig.
I also checked how my action was published - it had the correct touchpoint type
and the tooling attached to it had the correct instructions.
Am I missing something?
BTW going back a bit, how do you think having touchpoints as service will help
with the manipulator problem?
Thanks,
Borislav
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Pascal Rapicault
Sent: Thursday, August 11, 2011 7:40 PM
To: P2 developer discussions
Subject: Re: [p2-dev] touchpoints and manipulators
The EclipseTouchpoint is the one initializing the manipulator (see
EclipseTouchpoint#getManipulator()) and it "injects" the manipulator to the
actions themselves, so no potential issue jumps in mind atm.
I don't have any other ideas on dealing with the action reaching out to the
service. Maybe if we ever managed to get the actions be contributed through
service, then you could use DS or something like that.
On 2011-08-11, at 6:29 PM, Kapukaranov, Borislav wrote:
I've thought of that, haven't tried it though.
Assuming the contribution works fine do you think there will be problems with
several actions that need access to the manipulator.
For example if the InstallBundleAction and my action for scoped plans work
together in a single provisioning operation of a plan and a bundle can there be
any synchronization problems? Different views of the config data?
In theory I feel this should work fine, but what I couldn't figure out is how
to handle in a good way the initialization I need in my actions that is
provided only by my touchpoint and isn't by the EclipseTouchpoint - for example
a service.
One idea is to lookup my dependencies directly in the action's code but that
feels as a bad practice, although it should work.
Do you have any suggestions?
In the mean time I'll check if actions can be harmlessly contributed to the
Eclipse Touchpoint.
Thanks,
Borislav
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Pascal Rapicault
Sent: Thursday, August 11, 2011 6:47 PM
To: P2 developer discussions
Subject: Re: [p2-dev] touchpoints and manipulators
At this point the manipulator is seen as an implementation detail of the
Eclipse Touchpoint, which explains why it is not shared / exposed to others.
I suppose that we could start sharing it among various touchpoints (either
through service, or through explicit contract), but then comes the issue of
intertwining the lifecycles of the touchpoints. To be specific, we need to be
sure that all the touchpoints have the opportunity to validate what's there
before the operation is committed.
Instead, what should be possible is for the actions that need to access the
manipulator to be contributed to the Eclipse Touchpoint (see touchpointType
attribute in the declaration of an action) and thus gain access to it. When I
say contributed, they would not be part of the Eclipse Touchpoint bundle, but
just be seen as part of it.
Note that I have not tried that.
What do you think?
On 2011-08-10, at 3:08 PM, Kapukaranov, Borislav wrote:
Hi community,
As the work on the p2 and Virgo integration moves forward I stumbled across an
issue I thought was solved, but know I see we were just lucky and never had a
chance of solving it with this approach.
In Virgo there are special artifacts that are available for deployment such as
configurations and scoped plans.
I'll take the configurations as an example.
So in order to deploy them there is a new touchpoint and a new install action,
which takes the configurations published as IUs with iu properties and uploads
them to config admin.
This leaves two touchpoints(Eclipse and Virgo) which both has commit capability
and update the bundles.info<http://bundles.info>, but the trouble is that the
manipulators they use are different.
I thought that once the manipulator is initialized every touchpoint will use
that instance but apparently this was a wrong assumption. :(
The results I observed are that depending on which touchpoint.commit gets
called first by the engine, sometimes installed bundles are lost from the
bundles.info<http://bundles.info>because of the different manipulators.
For example EclipseTouchpoint writes first the b.info<http://b.info> with
correct data, as its InstallBundleAction was responsible for adding new bundles
and then comes VirgoTouchpoint which has an already old view of the
b.info<http://b.info> and deletes the just installed bundles (overwrites the
b.info<http://b.info>)
Is there a nice way to use one and the same manipulator in all available
touchpoints, or at least in all relevant touchpoints?
Thanks,
Borislav
_______________________________________________
p2-dev mailing list
[email protected]<mailto:[email protected]>
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
[email protected]<mailto:[email protected]>
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
[email protected]<mailto:[email protected]>
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/p2-dev
