Why not adopt a strategy where all org.eclipse.ui.* EP's are wrapped in an injectable part?
In August I proposed that we modify the class template / byte code to include the annotations (probably because that's when I first learned you could do something like that). If that is still a viable option I'm not sure it would be worth the amount of work. What I was really trying to get at with that proposal is using the existing API to treat all workbench contributions (o.e.u.* EP's) as E4 parts. Then there isn't an issue of mixing 3.x parts with 4.x parts because the workbench sees them all as 4.x parts. At the same point, if a 3.x part requests a separate workbench part (view / perspective / etc. ), it is relatively straight forward to provide it with a 3.x part. Even if the requested part is defined within a fragment, we can "mach-up" a bridge for the 4.x part to make it appear as a 3.x part. In my mind this provides a *true* compatibility layer. The migration story becomes simple at that point: *migrate what you want, when you want*. To migrate a view all you would have to do is break the inheritance from ViewPart (which wouldn't even be necessary) and add a couple of annotations. Maybe we create an optional @E4Part annotation. This way when we look to wrap the contributed part in an injectable E4 part, if any of @E4Part, @PostConstruct, @Focus, etc... are present the contribution isn't wrapped and treated as a raw E4 part. Then you wouldn't have to change **any** code except for adding a couple of annotations. *This would also allow you to have 3.x & 4.x parts contributed from the same bundle.* I have been working on something that demo's this functionality, but I recently started with a new company and haven't had much time. Hopefully in the next couple of weeks I will have something I can share. JD On Tue, Apr 23, 2013 at 10:26 AM, Jonas Helming < [email protected]> wrote: > Hi, > I have fixed a few minor issues on the wrapper classes in the last month. > I use them in a couple of projects. The typical users are bound to 3.x > because they use some components not available for e 4. I also think they > fit into the platform. However there is at least one thing to do, before I > would move them. Currently some of the services used in the wrappers are in > the tools.services plugin, some are in the compat plugin. The compat plugin > needs to provide wrapper interfaces for services which are different in 3x > and e4. > I already discussed that with Tom. IMHO, A good solution would be: move > all service interfaces to one plugin: compat.services. Create two > implementations: 3x and e4 in separate Plugins. > Additionally the CSS stuff should be moved into its own plugin, which > makes the compat plugin RAP compatible. > I have even started to make this refactoring. After that the compat plugin > would also be independent of any other tools plugin. > I agree with Lars, it should not be API in Kepler. I would be willing to > apply the changes described above, but I am currently not in office. When > is the latest date to move the plugins for Kepler? > Regards > Jonas > > > Von meinem iPhone gesendet > > Am 23.04.2013 um 20:42 schrieb Eric Moffatt <[email protected]>: > > I'm with John on tthis one...when running on top of a 4.x IDE there should > be no need for the part developer to even know about the legacy > implementations, the IDE itself should manage this since only it really > knows what the requirements are. As far as JD;s comments go this came up at > the BOF at EclipseCon this year with differing viewpoints being expressed. > For me I don't see extensions going away in 4.x; the tooling is all there > (Schemas, Docs, templates...) and the mechanism is both widely used and > understood by the Eclipse community. For folks that are coming from an > eclipse background (i.e. developed for eclipse before e4) this would > certainly be the expected route for them to use (so we can get them hooked > on e4...;-). > > Using the existing EP's may also provide e4 a quicker path to having a > fully functional 'editor' specification. The question remains whether the > e4 community should also be able to consume at least some of the extension > points directly (perhaps modified, see below). For me the answer is 'yes', > as part of moving things away from the IDE and into e4 is makes sense to > move the IDE code that scrapes the org.eclipse.ui.views registry and > creates the MPartDescriptors out to some place in e4. Deciding exactly > which EP's to consume should be done on a case by case basis (I..e do we > want to expose the current Perspective[Extension] EP or do we want to have > a simper one that rather than using IPerspectiveFactory just passes in an > MPerspective to be filled in using model code?). > > As the fragment story gets fleshed out some folks (particularly people > that haven't had any eclipse experience) may want to go that route because > the learning curve is shorter than learning how to use all the various > existing extension points. How many go this route will depend on how easy > we can make it and how god the docs are. > > Given that we wan to use the existing 'views' extension point let's see > what we need. The first part of the task is indeed fairly easy; check > whether the defined 'class' extends ViewPart and if not then just create it > through injection. There are a few things that complicate this though: > > - Various IDE API methods / events expose legacy implementation details > such as IViewPart, ViewReferences... (same for editors). We'll need to > create proxies to pass to satisfy these constraints. Since these are IDE > concepts the IDE should manage them. > > - The schemas define that the 'class' extend ViewPart and this gets used > by PDE's tooling to pre-populate the 'New Class' dialog when it's used (as > well as to filter the 'Find' results). Obviously we'll have to do something > here to loosen up these constraints. This same pattern will also be needed > for some of the other extensions (Editors, Handlers...). > > Hmmm, somewhat longer than I expected...;-). The upshot is that for folks > contributing to the IDE using modified versions of the existing EP's is the > right way to go. While it's less clear that e4 RCP apps *need *to use > EP's they're certainly useful and IMO would be of value even to EAP > developers. > > Eric > > > > <graycol.gif>Wim Jongman ---04/23/2013 05:59:04 AM---Yes, I think it is a > good idea from Patrick and John to automatically convert the view on the > fly. I > > <ecblank.gif> > > From: > > <ecblank.gif> > Wim Jongman <[email protected]> <ecblank.gif> > > To: > > <ecblank.gif> > > E4 Project developer mailing list <[email protected]>, > <ecblank.gif> > > Date: > > <ecblank.gif> > 04/23/2013 05:59 AM <ecblank.gif> > > Subject: > > <ecblank.gif> > > Re: [e4-dev] Move wrapper classes to platform? > <ecblank.gif> > > Sent by: > > <ecblank.gif> > [email protected] > ------------------------------ > > > > Yes, I think it is a good idea from Patrick and John to automatically > convert the view on the fly. It is a trivial thing (in my mind at least) to > check if this view implements iviewpart and if not, create a wrapper for it > so that it can be a first class citizen in the "mixed mode / IDE" story. > > I filed: > *https://bugs.eclipse.org/bugs/show_bug.cgi?id=406307*<https://bugs.eclipse.org/bugs/show_bug.cgi?id=406307> > > Lets take the discussion overthere > > Regards, > > Wim > > > > > On Mon, Apr 22, 2013 at 10:45 PM, Joseph D Carroll Jr <* > [email protected]* <[email protected]>> wrote: > > Where do people see the place of the plugin.xml in the long-run > (versus a fragment.e4xmi)? Certainly the plugin.xml will be used for > defining custom extension-points as it is now. But will any of the > org.eclipse.ui.* extension points survive, or is the sentiment to > [eventually] deprecate all of them in favor of fragments? > > If the preference in the long term is for fragments (+1), I would > think it would make more sense to focus on wrapping under the covers / > creating fragments on the fly from the plugin.xml 's. > > From a pure e4 standpoint, whatever story is adopted for contributing > pure e4 parts, I feel that it would be cleaner (and easier to learn) if one > was chosen (plugin.xml vs fragment.e4xmi) instead of having both locations > (IMHO). > > Right now it isn't clear to me if there is any preference. > > JD > > > > > On Mon, Apr 22, 2013 at 8:39 AM, John Arthorne <* > [email protected]* <[email protected]>> wrote: > You are both right, there is currently no story for contributing > pure e4 parts to the workbench. But does anyone think this is the right > answer in the long term? I would much rather see the existing extension > points change to accept pure e4 parts, and if any wrapping is required, > then *we* do the wrapping under the covers and not have plugin writers > explicitly reference or know about them. If we add these wrappers to the > platform and advocate that people use them, then when we come up with a > better answer next year we would have to ask them to migrate again. And > as > we all know, once they are available and people are recommending them, > it > becomes much harder to remove them later. I completely understand the > use > case and the short term benefit though. Maybe including them in the e4 > build and making them easier to consume is a middle ground that lets > people > use them if they want them, but makes it clear this is not the > recommended > long term direction? Anyway I leave it to Eric and Paul to make a > decision > here, it is maybe a good topic for the next e4 meeting. > > John > > > > > From: Lars Vogel <*[email protected]*<[email protected]> > > > To: E4 Project developer mailing list > <*[email protected]*<[email protected]>>, > > Date: 04/21/2013 03:21 PM > Subject: Re: [e4-dev] Move wrapper classes to platform? > Sent by: *[email protected]*<[email protected]> > > ------------------------------ > > > > John, > I agree with Tom. IMHO we have currently no story for IDE plugin > developer to use the new programming model without the wrapper classes. > > I'm more than happy to be corrected, is there a pure E4 way to > contribute to the IDE? > > On 19 Apr 2013 15:10, "John Arthorne" > <*[email protected]*<[email protected]>> > wrote: > If I remember correctly, the original intent of these wrappers was > to provide forwards-compatibility, that is allow you to write your > views/editors so they can run in both 3.x and 4.x while being able to > make > use of injection. Why would someone want to use such a layer in 4.3 and > beyond? At this point I thought the path we want to encourage is to drop > the ability to run in 3.x and move parts directly to the Eclipse 4 API. > I'd > hate to see people move to these parts and now have *two* layers of > cruft > between their parts and the Eclipse 4 framework (a forwards > compatibility > layer talking to a backwards compatibility layer talking to the > framework). > I see no problem that this stuff continues to exist for people who need > to > run on both 3.x and 4.x, but moving it into the platform somehow > sanctions > it as a good approach going forward. Is it? > > John > > > > From: Tom Schindl > <*[email protected]*<[email protected]> > > > To: > Cc: E4 Project developer mailing list > <*[email protected]*<[email protected]> > > > Date: 04/18/2013 04:11 PM > Subject: Re: [e4-dev] Move wrapper classes to platform? > Sent by: *[email protected]*<[email protected]> > > ------------------------------ > > > > Hi, > > Lars is right I wrote them ;-) and they are used without problems > by the > model editor since their inception. > > I think they are fairly done. There was a bug report from Jonas on > some > disposing or selection stuff which is not 100% ok. He had a patch i > revoked because it would have destoryed the active context. > > Like other things in e4.tools I'm not actively maintaining them > anymore > because my focus has shifted away a bit but I'm always available to > answer questions and take a glance at patches (like I just did with > Dirk > and broke the build the today/yesterday :-) > > Their original ident was to make the model editor run in *3.x* > (which it > still does?) maybe this support should be removed when moved to > eclipse > 4 proper? > > I'm with Lars, don't make them API but give them more visibility! > > BTW: There are many hidden secrets - I came up while doing the > tooling > dev - in the e4.tools repo like this (refcount resource management, > cool > new i18n support). Unless those get part of Eclipse Platform I plan > to > move them to e(fx)clipse and move on there (not everything there is > tied > to JavaFX) > > Tom > > On 18.04.13 21:34, Lars Vogel wrote: > > I definitely would be -1 on adding them as API but I think we may > be > > able to add them to the platform for Kepler as non API and > graduate them > > in 4.4. > > > > You find the relevant classes here: > > * > > http://git.eclipse.org/c/e4/org.eclipse.e4.tools.git/tree/bundles/org.eclipse.e4.tools.compat/src/org/eclipse/e4/tools/compat/parts > > *<http://git.eclipse.org/c/e4/org.eclipse.e4.tools.git/tree/bundles/org.eclipse.e4.tools.compat/src/org/eclipse/e4/tools/compat/parts> > They > > are relatively small. > > > > Its hard for me to answer your question about the shape do you > think > > they're in as I'm not familiar with the quality standards, maybe > Tom, > > the original author, can comment on that? If we don't consider > them API, > > we also have a few cycles left to clean them up, if necessary. > > > > Maybe someone from the platform can have a look at the classes > and tell > > us what we need to do, to graduate these classes. > > > > The nice thing would be that we would have a story for IDE > developer and > > the new programming model. > > > > > > 2013/4/18 Eric Moffatt <*[email protected]*<[email protected]> > <*mailto:[email protected]* <[email protected]>>> > > > > Lars, I'm +1 with caveats...;-) > > > > I haven't looked at these classes so I don't know what shape > they're > > in. My concerns are that this would effectively be adding new > API > > late in the cycle (past our usual time). If we want to > 'graduate' > > these classes to become part of the standard eclipse install > they > > have to be up to 'release; standard (which is much stricter > for IDE > > components than it is for incubation code). What are the > classes and > > what shape do you think they're in ? > > > > I wish this had been brought up earlier, it's obvious that the > > Platform is the right place for this code but I'm wondering > whether > > it may be better to hold off until Kepler releases and then > make > > sure that this happens *early* (M1) in Luna. During Luna I > hope that > > we can also look into graduating the Model and CSS editors > but we'll > > have to see how we can do this since graduating them will > place the > > code under the stricter 'Platform' standards and I don't want > to > > inhibit the excellent rate of progress. Perhaps this is a > non-issue > > since it's brand new code but we'll have to talk it over at > least. > > > > Eric > > > > > > Inactive hide details for Lars Vogel ---04/18/2013 09:35:43 > AM---Hi, > > The e4 tools project offers wrapper classes which allow > toLars Vogel > > ---04/18/2013 09:35:43 AM---Hi, The e4 tools project offers > wrapper > > classes which allow to wrap POJOs and > > > > > > From: > > > > > > Lars Vogel <*[email protected]* <[email protected]> <* > mailto:[email protected]* <[email protected]>>> > > > > To: > > > > > > E4 Project developer mailing list > <*[email protected]*<[email protected]> > > <*mailto:[email protected]* <[email protected]>>>, > > > > Date: > > > > > > 04/18/2013 09:35 AM > > > > Subject: > > > > > > > > [e4-dev] Move wrapper classes to platform? > > > > Sent by: > > > > > > *[email protected]* <[email protected]> <* > mailto:[email protected]* <[email protected]>> > > > > > ------------------------------------------------------------------------ > > > > > > > > Hi, > > > > The e4 tools project offers wrapper classes which allow to > wrap > > POJOs and perform DI on them. The wrapper classes provide the > old > > API, e.g. one of them extend ViewPart. This allows to use the > new > > programming model for plug-in development. Tom Schindl did > the the > > development. > > > > Is it an option to move the e4 wrapper classes to platform for > > Eclipse 4.3? This way people could easily start using the new > > programming model via the wrapper classes. > > > > I think as long as the wrapper classes remain in the e4 tools > > project their reach is relatively limited. > > > > IMHO offering the wrapper classes is a good start for a > migration > > story for the Eclipse plug-in developers. Also the wrapper > classes > > from Tom are relatively small. > > > > Best regards, > Lars_______________________________________________ > > e4-dev mailing list > > *[email protected]* <[email protected]> <* > mailto:[email protected]* <[email protected]>> > > > *https://dev.eclipse.org/mailman/listinfo/e4-dev*<https://dev.eclipse.org/mailman/listinfo/e4-dev> > > > > > > > > _______________________________________________ > > e4-dev mailing list > > *[email protected]* <[email protected]> <* > mailto:[email protected]* <[email protected]>> > > > *https://dev.eclipse.org/mailman/listinfo/e4-dev*<https://dev.eclipse.org/mailman/listinfo/e4-dev> > > > > > > _______________________________________________ > e4-dev mailing list* > **[email protected]* <[email protected]>* > > **https://dev.eclipse.org/mailman/listinfo/e4-dev*<https://dev.eclipse.org/mailman/listinfo/e4-dev> > > > > _______________________________________________ > e4-dev mailing list* > **[email protected]* <[email protected]>* > > **https://dev.eclipse.org/mailman/listinfo/e4-dev*<https://dev.eclipse.org/mailman/listinfo/e4-dev> > _______________________________________________ > e4-dev mailing list* > **[email protected]* <[email protected]>* > > **https://dev.eclipse.org/mailman/listinfo/e4-dev*<https://dev.eclipse.org/mailman/listinfo/e4-dev> > > > _______________________________________________ > e4-dev mailing list* > **[email protected]* <[email protected]>* > > **https://dev.eclipse.org/mailman/listinfo/e4-dev*<https://dev.eclipse.org/mailman/listinfo/e4-dev> > > > _______________________________________________ > e4-dev mailing list* > **[email protected]* <[email protected]>* > > **https://dev.eclipse.org/mailman/listinfo/e4-dev*<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
