Could we get rid of extension points at all and do contributions through DS?

Tom

Von meinem iPhone gesendet

Am 11.07.2013 um 19:17 schrieb Patrick Paulin <[email protected]>:

> I agree with Lars that option 1 is better. But is there a reason we couldn't 
> specify a POJO in the normal view "class" attribute? Whether the class 
> implements IViewPart or is a POJO that needs to be wrapped seems like an 
> implementation detail. 
> 
> --- Patrick
> 
> On Jul 11, 2013, at 4:34 AM, Lars Vogel <[email protected]> wrote:
> 
>> My understanding of 1.) is that the framework would accept Pojos. In would 
>> allow a smooth migration of the existing Eclipse IDE plug-in projects. 
>> 
>> 
>> 
>> 2013/7/11 Jonas Helming <[email protected]>
>>> Hi,
>>> I agree with Lars. However, even option 1 seems like a duplication of 
>>> fragments and processors to me. The main disadvantage for me       would 
>>> be, that you still stick to the old API. What is the advantage?
>>> Regards
>>> Jonas
>>> 
>>> Am 11.07.2013 11:22, schrieb Lars Vogel:
>>>> Hi Eric,
>>>> 
>>>> I think 1.) would be the right thing. 2.) feels like a duplication of 
>>>> model fragments and model processors to me.
>>>> 
>>>> Best regards, Lrs
>>>> 
>>>> 
>>>> 2013/7/10 Eric Moffatt <[email protected]>
>>>>> I'm currently looking at what we're going to do as far as extension 
>>>>> points go to enable folks to contribute e4 (DI) code into the IDE and I 
>>>>> want to get some feedback from the e4 community as to the best way for me 
>>>>> to do this...
>>>>> 
>>>>> I have two possible approaches:
>>>>> 
>>>>> 1) Extend the current IDE extension points with e4-specific sections 
>>>>> (i.e. extend the existing org.eclipse.ui.views EP to allow                
>>>>>    the addition of 'e4 View')
>>>>> 2) Provide separate extension points for the e4 bits (i.e. clone the 
>>>>> existing org.eclipse.ui.views EP and tweak it to be e4-related
>>>>> 
>>>>> Do you *want* e4 specific extension points ? This is independent of 
>>>>> having the ability to contribute them through fragment / model processing 
>>>>> (which we'll also be working on in Luna). The BOF at last year's 
>>>>> eclipsecon didn't come to a resolution on this (at least not one that I 
>>>>> remember..;-).
>>>>> 
>>>>> Let me know what you think,
>>>>> Eric
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> e4-dev mailing list
>>>>> [email protected]
>>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> e4-dev mailing list
>>>> [email protected]
>>>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>>> 
>>> 
>>> _______________________________________________
>>> e4-dev mailing list
>>> [email protected]
>>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>> 
>> _______________________________________________
>> e4-dev mailing list
>> [email protected]
>> https://dev.eclipse.org/mailman/listinfo/e4-dev
> 
> 
> 
> 
> _______________________________________________
> e4-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev

Reply via email to