[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[p2-dev] Isolating p2 from extension registry

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