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不足的地方又在哪里呢？哪些地方值得改进呢？

前几天忙着排练小品《大话读研》，是在迎新晚会上演出的，自己觉得自己蛮投入的，也可以看得出来，我们这个剧组的其他成员也都很投入，当然演出效果也比较令人满意，至少观众反映还是不错的，着实令人欣慰。不过，参加这个剧组，却让我体会到了另外一种感觉，那就是团队合作的精神，其实我觉着在这方面，我们现在很多人都存在着不足，但是很多人却没有意识到，而这次的合作，让我对团队精神有了新的理解，首先要有团队意识，比如开会，你要想着不能迟到，因为如果你迟到，等待你的将是整个团队，你浪费了所有人的时间，所以要心有团队。其次，团队说白了其实就是由很多人组成的，所以你必须同团队里的每个人交互，有时需要保留个人意见，有时需要及时纠正别人的做法，也就是说团队最后的走向取决于大家的合力，如果一个团队里面大多数人都很消极或者说做错了，那么可想而知这个团队的结果是什么了，要么解散，要么演出失败。最后一点团队需要一个有力的“领导”，我这里对领导加引号，是因为我并不是说领导代表一种权利，高人一等，随便发号施令，我认为领导在团队中的作用是协调、沟通，在团队中存在争议时，能迅速解决争议，使的团队的进步不因个人的问题而停止或中断，另外对团队领导的要求就是要有计划，有合理的安排，使得每个人能够尽量独立的发挥自己的聪明才干。

与此同时，我又参加了整场晚会的场地负责工作，包括预定场地、入场检票、分发食品、颁奖、音乐控制等。由于缺乏经验加之没有计划好，晚会刚开始的时候，场地一片混乱，入场处拥挤不堪，音乐控制处找不到伴奏带等，我是又忙又急，还好在大家的集体努力下，很快扭转了局面，也使我再一次感受到了团队的力量。

总结起来，这次晚会之所以出现开场时的混乱局面，我认为有以下几个原因：

1、  我们工作人员入场太晚，而这又是因为我们跟场地预定处没协调好

2、  食品与奖品等运到现场也太晚，直接导致了入场检票一度无法做，以及音乐控制处在等节目单和伴奏带

3、  整体没有配合好，比如场地如何布置，没有人告诉我们该如何安排，导致后来节目快开始的时候又重新安排

这又使我想起莉莉（偶GF）的一句常说的话，“凡事尽量提前准备好”，不错，这次我们就是在没有提前准备好，导致了现场的混乱。

对于我个人来说，这的确是第一次负责这种工作，所以没有什么经验，对于突发情况的处理显得手足无措，但同时也给我一次锻炼的机会，虽然当时说了很多抱怨的话，但其实我还是不后悔负责这个工作，因为它让我领会到一个小小的活动，想要把它搞好，也并不是很容易的。“麻雀虽小，五脏具全”嘛！