| Right. There is no expressed need to mix and match contribution mechanisms.
I'd like to see an approach that can be used in other places. Removing preferences for example. I'm not sure where all p2 uses prefs but we could likely do with some simple store/retrieve interface or even something domain/use specific (e.g., IRepositoryLocationStore). This may or may not be backed by prefs. Similarly with the action lookup stuff and the extension registry.
For example if there were an IActionManager that had getAction(String actionId, ITouchpointType type, VersionRange versionRange) then it would be possible to provide something like the current implementation or a replacement that used some other means of discovering actions.
We don't need some big infrastructure to deal with this, just some more context free code.
I am NOT in favor of flipping p2 to not use prefs, extensions, ECF etc for all cases. There are people who want p2 using different infrastructure. We should enable that but not program to the lowest common denominator. Jeff
On 2010-11-17, at 6:32 AM, Pascal Rapicault wrote: Just to try to restate the goals as I understood them. 1) remove the dependency on the extension registry 2) keep all the functionalities of the agent as they are (e.g. should be able to install the SDK, maybe the actions are contributed differently) 3) keep the laziness we have in p2 It is certainly not the goal to allow for the "pluggability" points to be themselves pluggable... For example we don't want to allow some of the p2 actions to be contributed through DS, others through extensions, others through... To continue on the example of actions, we do have today a concept of ActionManager that encapsulates the logic to get an action. It is currently bound to the extension registry. The initial proposal was to replace all the extension registry call by service calls, which I don't find really elegant. On the other hand, it is not clear to me if adding yet another layer of indirection really help and how much reduction we actually get when all the references to the extensions have been removed. On 2010-11-16, at 3:59 PM, Jeff McAffer wrote: Hey Katya,
I'm not suggesting that everything be a service rather that the things needed by an element of the system be injected into it. In the case of touchpoints and actions they may or may not make sense as services. My point is that the Engine should not know or care either way. One example in the Toast code is the web portal in Chapter 13 (you can get this from http://equinoxosgi.org). There we have an IActionLookup mechanism that returns "actions". There are implementations that are backed by the service registry and some backed by the extensions registry. The web portal (user of IActionLookup) is isolated from the choice of extensibility mechanism.
Something similar could be done in p2 to allow touchpoint and action lookup (for example) to be looked up. It would have the nice effect that if you want to plug in some other extensibility mechanism, you just provide an implementation of IActionLookup. p2 no longer reaches out and grabs stuff.
Jeff
On 2010-11-16, at 12:31 PM, Todorova, Katya wrote:
Hi Jeff,
I looked at the Toast example and I think it's a great guide for development.
It's nice to use DI, what I can't see is how using DS isolates you from OSGi? I think that defining OSGi sevices declaratively helps you only not to care about tracking your dependencies manually. Though in some cases it adds unneeded complexity.
Let me take for example Eclipse touchpoint and the actions it provides - what is the point to declare them as DS components as they should be immidiate and don't need anything injected by the framework? They are still OSGi services. Maybe I miss something?
Thanks a lot,
Katya
-----Original Message-----
From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On Behalf Of Jeff McAffer
Sent: Thursday, November 11, 2010 5:30 PM
To: P2 developer discussions
Subject: Re: [p2-dev] SAP Contribution
http://wiki.eclipse.org/Toast#Getting_started
The code in and of itself is not that useful in this case. It is more an example of a good sized system that uses OSGi but isolates itself from OSGi via DI and DS.
I'd be happy to talk about particular scenarios etc and point to relevant places in the code.
Jeff
On 2010-11-10, at 1:09 PM, Pascal Rapicault wrote:
Thx for the pointers Jett. This is indeed one of the direction Katya and I had discussed.
Do you have precise pointers in the Toast code?
On 2010-11-10, at 12:16 PM, Jeff McAffer wrote:
Overall this is a great direction.
At Eclipse Summit Pascal mentioned that replacing extension points with services for example could lead to unexpected side effects.
So before contributing back changes like this one, I would like to discuss them in the mailing list - is there a better solution, do they fit into p2 architecture, etc.
Ideally we would move to more of a dependency injection technique so p2 is not coupled to services or extensions. For example, in the Toast example (http://wiki.eclipse.org/Toast) for the OSGi book (http://equinoxosgi.org) we used a interface that provides the things needed. We provided service backed and extension backed implementations. Much nicer.
Jeff
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________ p2-dev mailing list p2-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/p2-dev
|
