Eclipse的一些概念.
Eclipse环境非常的庞大，但是有一些非常基础的概念和机制，这章我们将介绍这些概念，定义一些技术术语，最终的目的是向你展示Eclipse是如何组织在一起的，包括物理上和概念上。
尽管你已经熟悉Eclipse了，你可能想要跳过本章，但是写RCP应用程序还是和仅仅写一个插件还是有区别的，插件只是在扩展开发环境，而RCP应用程序意味着，你的应用是一个无论从功能还是产品的角度来说，都需要一个全面的考量。
基本的模块化单元就是叫做“plug-in”，或者在OSGI里叫“bundle”，Eclipse里的一切都是plug-in，那么一个RCP应用就是插件的集合以及他们运行的框架，这些新的插件包含了应用，产品定义，另外理解Eclipse怎样管理插件，怎样用他们，那些是可以用来调用的，那些必须自己写。
小范围的插件非常容易管理。插件逐渐变成了一个池子，随着你的应用程序的发展。分组抽象是必须的，用来帮助隐藏一些详细的细节。Eclipse团队定义了一些粗粒度的插件。
现在让我们看看插件内部细节，一个插件是一组文件的集合，一个manifest文件描述了插件本身，以及和其他插件的关系。
一个插件可以可以包含代码，也可以仅仅包含只读内容，如：图片，网页，国际化文件，文档等等。有些插件还有一个plugin.xml文件，历史上，这个文件存储了执行信息，现在包含在了manifest.mf文件里，plugin.xml文件继续作为扩展和扩展点声明文件。
约定下，文件系统的名字匹配插件的唯一标识和版本号，"configuration location"目录当前软件的配置信息，描述了哪些插件被安装和运行，也存储了一些插件的配置信息，首选项配置，缓存的索引，默认情况下，配置作为安装目录的一部分，这是约定的在一台机器上单用户有完全控制权限，当然你也可以放在当前用户的主目录。
OSGI框架。Eclipse的插件组件模型基于Equinox，它实现了OSGIR4.2版本，在Eclipse里面plug-ins和bundles没有根本和功能上的区分，都是分组，交付，管理代码的一种机制，事实上，传统的Eclipse plugin API仅仅是一个瘦，可选的层为了方便OSGI bundles功能划分，对于Eclipse，所有都是一个bundle，所以从用户的角度来看，plug-ins和bundle是一样的。
OSGI框架对java提供了组件模型，OSGI框架管理bundles通过类加载器，每一个bundle都有自己的类加载器，bundle的classpath基于manifest文件动态的构造，在Eclipse的上下文中，OSGI的主要角色是组织安装的插件，允许他们去交互和协作，严格的依赖管理，classpath的明确管理bundle间的交互，使创建的系统更容易的组合和灵活。
OSGI和Eclipse的关系，OSGI在Eclipse项目开始的时候独立的成立。它原始的目的是为java提供一个组件服务模型，去构建嵌入式的应用程序。
在Eclipse 3.0的开发周期中，RCP重点分拆的技术项目（http://eclipse.org/equinox），它使Eclipse运行时更加动态和支持插件安装和卸载不重新启动。在现有的各种备选方案进行了审议，发现OSGi成为一个标准，动态的框架，和Eclipse非常类似。结果是，Eclipse是基于Equinox实现了OSGi框架规范。在Eclipse3.5包括org.eclipse.osgi_3.5.0.jar一个独立的OSGi实现。
Equinox，历史上，Eclipse运行时包含了插件模型和各种功能元素，就像你看到的一样，plug-in或者bundle模型以及被移动到了OSGI层，这个是通过Equinox项目实现的，Eclipse原先提供的大部分功能也作为了Equinox项目的一部分，因此在这节，我们讨论了OSGI的基本标准和增值的功能元素Equinox。
Application，像JVMs和标准的java程序，OSGI系统需要被告诉具体做什么，OSGI的开发者定义了一个APP，这个app非常想普通的java程序的main方法，在Equinox启动后，它寻找和运行特殊的APP，APP用extensions定义，application扩展一个指定的类，作为程序的主要入口点，当你运行Eclipse的时候，你需要指定一个特殊的APP去运行，一旦被激活，这个APP就完全在Eclipse的控制下了，当app退出的时候，Eclipse也就退出了。
product，是在一个application上一层的，Eclipse包含了很多的application和product，但是在运行的时候，只有一个产品和application结对在运行。
Extension Registry,OSGI提供了一种定义和运行独立的插件的机制，和一个服务机制，支持bundle间的协作，Equinox提供了一种插件间声明关系的机制：Extension Registry. 插件可以声明一个扩展点，意味着，插件本身预留了一个接口，那么其他插件就可以提供需要的信息，这样就实现了一个可扩展的框架。
这个例子的典范是 UI 插件，和它的"actionSets" 扩展点，简单说来，action-sets是UI怎样描述menu和toolbar，Eclipse UI暴露了org.eclipse.ui.actionsets扩展点，就好比说，我声明了一个扩展点，定义一个action需要一个ID，label，icon，和实现IActionDelegae接口的类，UI将会展现label和ICON给用户，当用户点击它们的时候，UI将会实例化action类，转换成IActionDelegate，调用它的 run()方法。
这些关系被定义在plugin.xml里面，每个插件都有一个这样的文件，这种看起来简单的关系，实则非常给力，菜单允许用户添加，UI插件不需要知道用户将要添加什么，但是接口留给你了，你看着办！并且没有代码允许，所有都是声明式和懒加载的。这种注册机制是Eclipse的关键特性。
SWT，在OSGI和Equinox旁边的是SWT，它是一个底层的图形库，提供了List，menu，font，和颜色。这个库暴露了底层操作系统提供的功能，就像SWT团队说的，SWT提供了有效，方便的访问OS的UI特性，这些都被SWT实现了。基于SWT的系统不依赖Equinox和OSGI，可以独立运行。
JFace，在SWT的基础上提供了更方便操作的API，包含了许多公共的UI编程任务，从图像，字体注册，文本支持，对话框，数据绑定，属性页，长时间操作机制，JFace UI 结构，例如action和views，作为Eclipse UI的基础。
UI Workbench，就像Jface添加了功能对于SWT一样，workbench添加了一直的更具体的ＵＩ ＡＰＩ，对于用户来说，Ｗｏｒｋｂｅｎｃｈ考虑了想ｖｉｅｗｓ和ｅｄｉｔｏｒｓ等。提供了基于可扩展的ＵＩ基础，定义了强大的windows,perspectives,views,editors和actions的范例。
Workbench提供了Extension Registry机制的样板，方便开发者调用，除了声明式外，“capabilities”机制允许定义过滤action，直到定义需要的action被触发，你的应用有大量的action，但是用户只想看到他们感兴趣的，对于用过Eclipse的童鞋都知道，在不同的上下文点击鼠标右键，弹出来的菜单是不一样的。
因为所有的这些扩展都是懒加载的，因此应用的规模更好控制，当你的应用变得richer，它就会包含更多的views，editors，和actions，没有声明式的扩展机制，增长的同时增多了额外的加载和代码执行，这样就增加了代码的体积和启动时间，应用也显得不灵活，用了注册机制，没有代码加载，除非到它出场。
Perspectives，Views，和Editors，Workbench给用户展现的是窗口的集合，Workbench允许用户组织他们的工作就像同样的方式你组织你的桌面，一个Perspectives是一个可视的容器包含了views和editors的集合，展现给用户的所有东西都是在一个views或者editors里，它们又被布局在一个perspective里。
一个Perspective支持一组特殊的任务，用户可以切换不同的视图，用过Eclipse开发的童鞋，一定在java和debug视图切换过，让用户用着更舒心。
总结： 在Eclipse里，一切都是插件，甚至OSGI框架和Equinox也展现为插件，所有的插件通过扩展注册机制相互作用，这些功能对于所有的插件可用。没有秘密后门和未包含的接口，如果功能可以在Eclipse IDE里用，那么也可以在你的应用里使用。
SWT，JFace，和ＵＩＷｏｒｋｂｅｎｃｈ组成了一致的强大的ＵＩ让你构建可扩展，灵活的用户体验。简单的说，Ｅｃｌｉｐｓｅ是一个理想的技术对于构建基于OSGI的模块化RCP应用。
下一章，就会以一个例子来说明如何开发RCP应用。