Eclipse机制以及OSGI的体会

此文档是总结性文档，较宽泛，适合对Eclipse 插件开发有一定了解的同事查阅。 
始终忙于插件开发，对eclipse 得本质并未深入研究，在这段时间的studio 技术总结期间，梳理代码时，对已底层的机制认识不清，借此机会深入研究了一下。 
 
在网上google 了下，对OSGI 的定义如下： 
OSGi 是什么，OSGi 是一种服务运行平台。通过实现能够提供服务的符合OSGi 规范的组件，用户可以将其组件发布到OSGi 运行平台，供用户和其他组件使用。OSGi 组件提供的服务具有两个层面的含义：系统层面，即一个组件为其他组件提供服务，这些服务体现为Java 接口的实现；业务层面，即一个组件为外部系统或用户提供某种业务服务实现。 
 
这种解释比较抽象不太好理解，我总结下了粗浅得概念以及好处： 
OSGi 可以控制访问范围，这方面Java 本身控制得不够细，比如我某个类只希望供某些指定的类使用，Java 是无法做到的（Proptected 只能供同包和子类用）。一句话：osgi 其实就是个classloader （刘成帮语）。 
拿J2EE 来说，一个web 应用通常只由一个project 来完成，所有得实现均在此project 中完成，web 应用发布后，若以后新增功能，那么只能在此工程下添加包、类等等，然后再编译打包发布。 
而OSGI 框架是由多个project 组成，此project 被OSGI 命名为Bundle （包），每个bundle 有具体的服务或者功能，如果想增加一个全新的功能，那么你只需再开发一个bundle 并部署上就可以了（OSGI 支持热插拔），Eclipse 的插件化概念就是基于OSGI 的理念。 
OSGI 理念，我认为是未来的一个方向，把软件开发转向模块块开发（构件化）的方向，同时这也是一种软件设计理念，OSGI 告诉我们，写软件的时候要把职责划分清楚，这是合理划分接口、类、包甚至是服务，组件的基础。以R1Studio 为例，我们在软件设计划分时从大块上划分为Platform ，以及各产品插件。Platform 是运行得基础，主要包括运行的核心包，例如core 包，model 包，ui 包等等。各产品插件包依赖于platform ，各个bundle 各司其职，职责清楚，如果想修改DE-I 的业务，那么只需到DE-I 的bundle 去修改。如果在底层新增个通用的功能，例如调用消息格式，那么只需在platform 里修改，其他产品插件就获得了这个调用功能。若新增了XX 产品插件，就需要再创建一个bundle 。 
 
Eclipse 与OSGI 的关系以及实现 
 Eclipse 插件开发在OSGI 的显现表现方式是，每个插件（bundle ）里有个META-INF\MANIFEST.MF 文件，此文件的定义是符合OSGI 规范的，以com.icss.ro.studio.xprocess 为例，打开MANIFEST.MF ，节选一个片段，如下所示： 
 
Manifest-Version : 1.0 
Bundle-ManifestVersion : 2 
<p align="l

Eclipse机制以及OSGI的体会

浏览过的版块