概述
Eclipse中最出彩的部分莫过于它的Plugin Framework,可以说Eclipse在一定程度上使得Plugin机制得以流行,当然,Eclipse的优势不仅仅在此,但正因为采用了Plugin机制,Eclipse才得以被不断的扩充,越来越强大。一直以来就想分析Eclipse的Plugin Framework,由于各种原因一直耽搁,刚好这个周末没什么事,下定决心对其进行了研究和分析,方法很原始,就是对Eclipse的启动过程进行分析,基于的是Eclipse 3.1的版本,分析过程就不在这说了,主要是说说分析出来的心得。
架构上来讲Eclipse基本采用的是Kernel+Core Plugins+Custom Plugins的结构体系,除了Kernel部分外均为Plugin,所以可称为all are plugins,凡是Plugin的部分都是可被替换的。

OSGI
Eclipse 3.0后采用的是OSGI来作为其Plugin Architecture实现的依据,鉴于此就得简单提提OSGI了,主要从Plugin的角度来分析OSGI,OSGI概念中主要分为了Bundle和Service,可以认为Bundle是一个模块的管理器,主要是通过BundleActivator管理模块的生命周期,而Service则是这个模块可暴露对外的服务对象,这里体现了OSGI和传统的Plugin Framework不同的一个地方,管理和静态结构分开,在OSGI中通过在manifest.mf文件中增加一些内容来发布Bundle,在其中描述了Bundle的提供商、版本、唯一ID、classpath、暴露对外的包、所依赖的包;每个Bundle拥有自己的ClassLoader以及context,通过context可进行服务的注册、卸载等,这些操作都会通过事件机制广播给相应的其他的Bundle;一般来说都为通过在Bundle中编写初始需要注册的服务的方法来完成Bundle可供外部使用的服务的暴露功能;如需要调用其他Plugin提供的服务可通过context的getServiceReference先获取Service的句柄,再通过context.getService(ServiceReference)的方法获取Service的实体。

Eclipse Plugin定义
Eclipse中的Plugin的概念为包含一系列服务的模块即为一个Plugin。既然是遵循OSGI的,也就意味着Plugin通常是由Bundle和N多Service共同构成的,在此基础上Eclipse认为Plugin之间通常存在两种关系,一种为依赖,一种为扩展,对于依赖可通过OSGI中元描述信息里添加需要引用的Plugin即可实现,但扩展在OSGI中是没有定义的,Eclipse采用了一个Extension Point的方式来实现Plugin的扩展功能。
结合OSGI
Eclipse遵循OSGI对于Plugin的ID、版本、提供商、classpath、所依赖的plugin以及可暴露对外的包均在manifest.mf文件中定义。
Plugin Extension Point
对于扩展,Eclipse采用Extension Point的方式来实现,每个Plugin可定义自己的Extension Point,同时也可实现其他Plugin的Extension Point,由于这个在OSGI中是未定义的,在Eclipse中仍然通过在plugin.xml中进行描述,描述的方法为通过<extension-point id="" name="" schema="">的形式来定义Plugin的扩展点,通过<extension point="">的形式来定义实现的其他Plugin的扩展点,所提供的扩展点通过schema的方式进行描述,详细见eclipse extension-point schema规范,为了更好的说明扩展点这个概念,举例如下,如工具栏就是工具栏Plugin提供的一个扩展点,其他的Plugin可通过此扩展点添加按钮至工具栏中,并可相应的添加按钮所对应的事件(当然,此事件必须实现工具栏Plugin此扩展点所要求的接口),工具栏的Plugin将通过callback的方式来相应的响应按钮的动作。可见通过Extension Point的方式可以很好的提供Plugin的扩展方式以及实现扩展的方式。

Eclipse Plugin Framework
那么Eclipse是如何做到Plugin机制的实现的呢??还是先讲讲Eclipse的设计风格,Eclipse在设计时有个重要的分层法则,即语言层相关和语言层无关的代码分开(如jdt.core和core),核心与UI分开(如workbench.ui和workbench.core)这两个分层法则,这个在Eclipse代码中处处可见,在Plugin Framework部分也充分得体现了这个,遵循OSGI,Eclipse首先是实现了一个OSGI Impl,这个主要通过它的FrameWork、BundleHost、ServiceRegistry、BundleContextImpl等对象来实现,如果关心的话大家可以看看这部分的代码,实现了Bundle的安装、触发、卸载以及Service的注册、卸载、调用,在Plugin机制上Eclipse采用的为lazy load的方式,即在调用时才进行实际的启动,采用的为句柄/实体的方式来实现,外部则通过OSGI进行启动、停止等动作,各Plugin则通过BundleContext来进行服务的注册、卸载和调用,这是OSGI的部分实现的简单介绍。
那么Extension Point方面Eclipse是如何实现的呢,在加载Plugin时,Eclipse通过对plugin.xml的解析获取其中的<extension-point>节点和<extension>节点,并相应的注册到ExtensionRegistry中,而各个提供扩展点的Plugin在提供扩展点的地方进行处理,如工具栏Plugin提供了工具栏的扩展点,那么在构成工具栏时Plugin将通过Platform.getPluginRegistry().getExtensionPoint(扩展点ID)的方法获取所有实现此扩展点的集合IExtensionPoint[],通过此集合可获取IConfigurationElement[],而通过这个就可以获取<extension point="">其中的配置,同时还可通过IConfigurationElement创建回调对象的实例,通过这样的方法Eclipse也就实现了对于Plugin的扩展以及扩展的功能的回调。在Plugin Framework中还涉及很多事件机制的使用,比如Framework的事件机制,以便在Bundle注册、Service注册的时候进行通知。

总结
通过对Eclipse启动过程的分析,可清晰的看到Eclipse Kernel+Core Plugins+Application Plugins的方式,在代码中分别对应为loadBasicBundles和registerApplicationServices,loadBasicBundles通过加载config.ini中的osgi.bundles完成基本的bundles的加载,去看看这个配置会发现是org.eclipse.core.runtime还有一个update,core.runtime又会通过IDEApplication来完成整个Eclipse的启动,同时会注册所有与workbench相关的plugin。
Eclipse由于以前版本的Plugin Framework是没有采用OSGI的,所以通过EclipseAdaptor的方式来实现与以往的兼容,目前新的Plugin采用的方式基本就是manifest.mf描述Plugin OSGI部分的信息,Plugin.xml描述扩展点的信息。
Eclipse中有非常多优秀的设计,这个在看它的代码时会有很深的感触,比如Contributing to Eclipse中提到的Extension Object/Interface的设计,确实是非常的不错,虽然看到你可能觉得很简单,关键是要想得到并合适的去使用。
总结陈词,^_^,Eclipse Plugin Framework是采用OSGI Impl+Plugin Extension-Point的方式来共同实现的,实现了Plugin的部署、编写、独立的Classloader和Context、Plugin中Service的注册、Plugin中Service的调用、Plugin的依赖、Plugin的扩展、Plugin生命周期的管理。

带来的思考
Eclipse Plugin Framework采用的是OSGI的实现,一定程度上我们也能看到OSGI的优点,那么JMX+IoC方式的Plugin Framework与其的比较又是在哪些方面呢?Eclipse Plugin Framework不足的地方又在哪里呢?哪些地方值得改进呢?

posted on 2005-12-30 19:05 未来刀客 阅读(703) 评论(0)  编辑  收藏 所属分类: 技术随笔

只有注册用户登录后才能发表评论。


网站导航: