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 Lets take the discussion overthere Regards, Wim On Mon, Apr 22, 2013 at 10:45 PM, Joseph D Carroll Jr < [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]>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]> >> To: E4 Project developer mailing list <[email protected]>, >> Date: 04/21/2013 03:21 PM >> Subject: Re: [e4-dev] Move wrapper classes to platform? >> Sent by: [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] >> 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
