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]> To: Cc: E4 Project developer mailing list <[email protected]> Date: 04/18/2013 04:11 PM Subject: Re: [e4-dev] Move wrapper classes to platform? Sent by: [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 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] <mailto:[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] <mailto:[email protected]>> > > To: > > > E4 Project developer mailing list <[email protected] > <mailto:[email protected]>>, > > Date: > > > 04/18/2013 09:35 AM > > Subject: > > > > [e4-dev] Move wrapper classes to platform? > > Sent by: > > > [email protected] <mailto:[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] <mailto:[email protected]> > https://dev.eclipse.org/mailman/listinfo/e4-dev > > > > _______________________________________________ > e4-dev mailing list > [email protected] <mailto:[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
