I like option 1 as well. Generally, we should absolutely minimize the friction needed to migrate to the "new way". If possible, just lifting the restriction that the view must implement IViewPart seems like the easiest migration path for plugin writers. The flip side is that we would *only* attempt injection in the case where the object does not implement IViewPart - I don't think we want to support blended combinations of old API plus injection.
This has the advantage to me that we change the schema and the tooling no longer encourages developers to do things the "old way" at all. Of course PDE templates would also need updating to generate new style of parts. If there are good reasons we can't make old and new extensions work with exactly the same schema, then some minimal change to the schema to support both cases might be possible. We really need to experiment with this to see what works, but my general bias is: - All existing valid extensions must continue to work - Minimize migration effort for plugin developers as much as possible - Have schema and PDE templates encourage the "new way" when creating new extensions John From: Patrick Paulin <[email protected]> To: E4 Project developer mailing list <[email protected]>, Date: 07/11/2013 01:19 PM Subject: Re: [e4-dev] E4 Extension Points Sent by: [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
