当前位置: 代码迷 >> Eclipse >> 临时放弃e4,回到Eclipse 3.x RCP
  详细解决方案

临时放弃e4,回到Eclipse 3.x RCP

热度:483   发布时间:2016-04-23 12:25:11.0
暂时放弃e4,回到Eclipse 3.x RCP

e4,即Eclipse 4.0及之后的版本,标志着Eclipse作为一个平台革命性地提升。因为Eclipse从3.0开始正式全面基于OSGi的缘故,可以说Eclipse比其他任何IDE的模块化都做的更好。很多IDE都支持插件开发,但其本身很少能够做到模块化,一般都是本身是非模块化的系统,加上一个支持模块化的接口,从而允许第三方开发插件。只有Eclipse是由内而外完完全全的模块化。e4不仅仅延续且发扬了模块化,甚至还做到了完全的模型化,把最底层的UI和非UI模型全部开放出来,称为Application Model,而且减弱了传统的对接口实现,抽象类继承,以及extension points的依赖,取而代之的是依赖注入(dependency injection),又叫控制反转(reverse of control),加入了大量的annotation,使得开发变得非常灵活,模块之间耦合程度降低,模块的lazy initialization得到了优化。


继续展开说e4的好东西。

1、整个IDE的界面焕然一新



2、新增Quick Access功能支持全局搜索



3、取消了Eclipse 3.x中关于view和editor的区分,Eclipse 3.x中editor永远都在中央位置,而且editor永远不能和view并存于同一个stack里面,换句话说打开的java文件和Eclipse的Console view永远不能重叠在一起。e4就取消了这种本身就不必要的区分,不管view还是editor,都是part,是part就可以并存于partstack或者part sashcontainer里面。



4、进一步取消了Eclipse 3.x中对于不同UI模型的区分,比如只有editor和少量的几种view有dirty标志和保存功能。在e4所有UI模型都可以使用MDirtyable接口。



5、支持css文件实现外观,要不是e4实现了UI元素的彻底模型化,这是不可能实现的



其他优点还有很多,比如因为程序员可以直接接触到e4开放的核心模型,所以对基于Eclipse平台开发的项目有更多的控制权,可以放开手脚,有多大本事就能利用这些模型和服务开发出多好的企业级应用产品来。


下面说说为什么笔者正在做的这个RCP项目使用e4技术2周之后准备暂时放弃e4,仍然使用Eclipse 3.x技术。

Eclipse Foundation和下属的各个项目都是按Simultaneous Release的原则,定期地更新和发布新版本。

Release namePlatform versionMain releaseSR1SR2Links
Callisto3.2June 26, 2006N/AN/AWeb Site

Wiki

Europa3.3June 27, 2007September 28, 2007February 29, 2008Web Site

Wiki
Download Page

Ganymede3.4June 25, 2008September 24, 2008February 25, 2009Web Site

Wiki
Download Page

Galileo3.5June 24, 2009September 25, 2009February 26, 2010Web Site

Wiki
Download Page

Helios3.6June 23, 2010September 24, 2010February 25, 2011Web Site

Wiki
Download Page
Repository

Indigo3.7June 22, 2011September 23, 2011February 24, 2012Web Site

Wiki
Download Page
Repository

Juno4.2June 27, 2012September 28, 2012February 22, 2013Web Site

Wiki
Package Download Page
p2 Repository

Kepler (planned)4.3June 26, 2013September 27, 2013February 28, 2014Wiki

e4是在Juno才发布,而Juno都要到明年2月低才稳定。其实现在不能说不稳定,但笔者感觉Eclipse核心开发的那帮人把很多精力都花在了“向下兼容”,即如何在发布e4的同时保证基于Eclipse 3.x开发的项目在Juno里也能跑,即所谓的compatibility layer。现在e4最底层的东西都有了,这也意味着现在如果基于e4搞开发,就要从底层搞起,举个简单的例子,Eclipse 3.x中要实现一个package navigator,直接写一个navigator类继承CNF(Common Navigator Framework)就行了,1分钟搞定,基本功能包括右击菜单直接就有了。而在现在的e4,全部都要从模型开始做起。


这还不是最复杂的,因为笔者的项目里面需要一个diagram editor(类似下图),这是要基于Eclipse的draw2D和GEF技术的。draw2d比较好办,毕竟只是把模型图形化,关键是GEF,需要通过对图形的操作影响模型。GEF截止目前还没有支持e4,可能要到明年夏天的Eclipse Kepler(4.3)版。没办法,只能放弃e4,使用已经成熟的Eclipse 3.x技术。等什么时候e4框架更完善了,GEF等项目全面支持e4了,笔者非常有兴趣用e4的这些新技术重写一遍。








  相关解决方案