+1 from me as well on adding the wrapper classes into the platform for 4.3.
Even for those starting fresh with RCP there are cases where a pure e4 implementation is not possible. Many RCP applications incorporate other Eclipse components that have not yet been converted (CNF, GMF/Graphiti, etc.) My suggestion to those teams is to use the wrapper classes, and it would be great if they were easier to incorporate. Another option would be to allow putting POJOs directly into view, editor, and handler extensions and then creating the DI instances on the fly. Not completely sure if this is possible, but it would eliminate a lot of boilerplate wrapper subclasses and keep the DI classes out of the API. Regards, --- Patrick On Apr 19, 2013, at 8:20 AM, Wim Jongman <[email protected]> wrote: > This model is not meant to be used by starters. They can skip this > completely. However, there is a huge installed base that wants to move > forward with E4 but cannot do it because of the current inability to mix the > two programming models. At the moment it can be used but if it is not > officially supported and documented by platform then it will be considered a > hack and people will keep on running their complete rcp in compatibility > mode. > > Not being able to "officially" run in mixed mode will severely hinder the > adoption of E4. > > Regards, > > Wim > > > > On Fri, Apr 19, 2013 at 3:09 PM, John Arthorne <[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]> > 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 > > > _______________________________________________ > 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
