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]] 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, 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.infobecause of the different manipulators. > For example EclipseTouchpoint writes first the 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 and deletes the > just installed bundles (overwrites the 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] > 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
