I agree fully, in principle that is ;) Whatever can be done in Platform, should be done in Platform so it benefits everyone directly.
Picking up the example of the spell checker, I guess bringing the default engine implementation and dictionary into platform.text would be a no-brainer (actually, I forgot about the platform.text/jdt relationship here when picking that example - it's been a bit since I looked into it and only remembered that JDT had the implementation I needed). What's going to be interesting is how to deal with cases where that's not a given - i.e. where we don't know the best way yet and have to try out a few things, or where the change is more controversial and first has to prove itself. I think hosting intermediary code, staging private builds of some Platform or other external bundles based on Gerrit changes (or even doing temporary forks) can play a role there. > -----Original Message----- > From: e4-dev-boun...@eclipse.org [mailto:e4-dev-boun...@eclipse.org] On > Behalf Of Mickael Istria > Sent: Thursday, July 6, 2017 2:13 PM > To: E4 Project developer mailing list <e4-dev@eclipse.org> > Subject: Re: [e4-dev] Sandbox for Eclipse proposal as E4 sub-project > > Thanks for those answers Carsten. > > I see some of the work you're willing to do as very interesting for the > Platform as a whole. I think it makes sense to write some new experimental > code that's necessary in e4, but if we consider for example the spell- > checker, I wouldn't advise working on it as a new project in e4 as it > would derive too much from initial JDT / Platform-Text and risks of never > be merged back to those projects. If you can try to improve stuff in > Platform without using intermediary code in e4, I believe the chances of > success are higher. > > > Cheers, _______________________________________________ e4-dev mailing list e4-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/e4-dev
