Eclipse完全手册
Eclipse是一个开放源码的、可扩展的应用开发平台，该平台为编程人员提供了一流的Java 集成开发环境。作为一套开源工具，可用于构建Web Services、J2EE等各种类型的应用，其所提供的功能不亚于、甚至要超过由专业的集成环境供应商所提供的商业化产品，如JBuilder。
Eclipse最有魅力的地方就在于它的插件体系结构。在这个体系中重要的概念是扩展点（extension points），也就是为插件提供的接口。每一个插件都是在现有的扩展点上开发的，并可能还留有自己的扩展点，以便在这个插件上继续开发。
由于有了插件，Eclipse系统的核心部分在启动的时候要完成的工作十分简单：启动平台的基础部分和查系统的插件。在Eclipse中实现的绝大部分功能是由相应的插件完成的，比如WrokBench UI插件完成界面的外观显示，Resource Management插件完成维护或生成项目或文件等资源管理工作，而Version and Configuration Management（VCM）插件则负责完成版本控制功能，等等。虽然以上提到的每一个功能都是绝大多数IDE环境所必备的功能，Eclipse 却把它们都做成了插件模式，甚至用来开发Java程序的开发环境（Java development tooling，JDT），也只不过是Eclipse系统中的一个普通插件而已。整个Eclipse体系结构就像一个大拼图，可以不断地向上加插件，同时，现有插件上还可以再加插件。
虽然大多数用户很乐于将Eclipse当做Java IDE来使用，但Eclipse的目标不仅限于此。Eclipse平台为工
具提供者（Tools Provider）提供一套使用机制和一组需要遵循的规则，从而使得开发出的工具之间可以实现无缝的集成。这些机制通过定义良好的API接口、类和方法提供给用户使用，平台同样为新的工具的开发提供强有力的组件支持（如Plug-in Development Environment，PDE——插件开发环境）。主要针对希望扩展Eclipse的软件开发人员，因为它允许他们构建与Eclipse环境无缝集成的工具。由于Eclipse中的每样东西都是插件，对于给Eclipse提供插件，以及给用户提供一致和统一的集成开发环境而言，所有工具开发人员都具有同等的发挥场所。
这种平等和一致性并不仅限于Java开发工具。尽管Eclipse是使用Java语言开发的，但它的用途并不限于Java语言；例如，支持诸如C/C++、COBOL和Eiffel等编程语言的插件已经可用，或预计会推出。Eclipse框架还可用来作为与软件开发无关的其他应用程序类型的基础，比如内容管理系统。
基于Eclipse的应用程序的突出例子是IBM的WebSphere Studio Workbench，它构成了IBM Java开发工具系列的基础。例如，WebSphere Studio Application Developer添加了对JSP、Servlet、EJB、XML、Web服务和数据库访问的支持。
尽管大多数开发人员不会使用Eclipse来开发插件，或创建基于Eclipse的新产品，但是Eclipse的开放源代码性质所意味的，并不只是它使得Eclipse免费可用（尽管便于商业化的许可证意味着插件可能要花钱）。开放源代码鼓励创新，并激励开发人员（甚至是商业开发人员）为公共开放源代码库贡献代码。
为这个项目作贡献的开发人员越多，这个项目就会变得对每个人越宝贵。随着这个项目变得更加有用，更多的开发人员将会使用它，并围绕它形成一个社区，就像那些围绕Apache和Linux形成的社区一样。
<协会管理和指导Eclipse正在进行中的开发。据说IBM花了4000万美元开发Eclipse，并把它作为一个开放源代码项目发布。之后，协会吸收了许多软件工具提供商，包括Borland，Merant，Rational，RedHat，SuSE，TogetherSoft和QNX。从那以后还有其他公司相继加入，包括Hewlett Packard，Fujitsu，Sybase。
如图1-1所示（摘自Eclipse），自从2001年发布第一个版本开始，Eclipse逐渐地被越来越多的开发人员所采纳，其功能和需求也在不断地更新和变化中。
图1-1  Eclipse发展历程
1.0版本的目的纯粹就是作为一个Java集成开发平台，就如JBuilder和VisualAge那样。
在1.0版本的应用过程中，由于Eclipse的开源特性，Eclipse社区不断地从其广大的Fans 那里得到新的灵感，特别是一些面向最终用户的技术支持人员，他们往往会面对客户这些提问：
为何你所提供的产品不与其他公司提供的工具集成？
为何不能把某个工具产生的数据导入到其他工具中去？
为何在不同程序之间进行导入和导出时遇到了问题？
为何程序在执行相似的任务时却有着完全不同的用户界面？
为何不将Web站点设计工具与脚本编制程序集成？
为了解决以上的用户需求，Eclipse被重新设计和定位，并于2002年推出了2.x版本。Eclipse 转变了自身的角，从一个单一的集成开发环境转变为一个开放的可扩展的集成平台。它能将单独开发的工具融合到精心设计的套件中；它可以很容易地将现有工具移植到平台中；它是开放式的，让人容易理解，
并且功能强大，不需要额外的努力就可以支持集成；它提供工具从而有助于使常见的任务自动化；它足够稳定，可以在它上面构建业界领先的工具。
2.x版本的Eclipse平台可以达成以下目标：
支持用于应用开发的各种工具的构建。
支持非受限的工具提供者，包括独立的软件提供商。
支持用于操作任意类型的文件（HTML，Java，C，JSP，EJB，XML，GIF等）的工具。
推动各种工具的无缝集成。
支持GUI（图形用户界面）和非GUI的应用开发环境。
免费平台源码资源网运行于多种操作平台（Windows，Linux和Solaris）。
利用Java编程语言的普及来推动应用工具的开发。
2.x版本在应用过程中的确达到了其所提出的目标，但是新的问题随之而来，举个例子来说，基于Eclipse我们开发出了一套工具，但是如何提交给客户呢？要将整个Eclipse集成开发环境都给用户打包
过去吗？那太荒唐了，客户可不需要包含一个集成开发环境的产品。另外，许多插件并不是集成开发环境所专有的，它们完全可以脱离Eclipse而单独使用，最主要的是：先进的桌面应用有许多相似之处：帮助系统、升级管理、配置管理、开放的架构，等等，Eclipse集成开发环境的整个架构经历了无数的测试，已经证明是健壮的和一流的，这些东西为什么不能提供给用户用于桌面开发呢？
因此，自2.1版本开始，Eclipse社团内部启动了新的研究项目：基于Eclipse的集成开发环境构建技术。主要用来实现非集成开发环境的应用，换句话说，将Eclipse可扩展架构进行重用，开发出具备Eclipse新特征的应用。这就是Eclipse RCP（Rich Client Platform）的前身。富客户机程序（Rich Client）并不是一个新的名词，在20世纪90年代曾经风靡一时，但是随着Internet和基于Web的应用的不断发展，瘦客户机程序（Thin Client）成为了一项通用的解决技术。它可以解决富客户机程序所带来的诸如管理不便和升级成本高昂等问题。以放弃了用户界面的特和高速的用户交互为代价，降低了部署和维护企业应用的费用。降低费用和简单化是很受欢迎的，但是向瘦客户机程序迁移在根本上是一种功能和性能上的倒退。瘦客户机程序采用请求-应答模型，所以要求更大的网络容量以确保最佳的交互效果。随着应用和用户本身变得越来越复杂，以及大量的新的需求（分布式的业务逻辑、操作移动设备、非互联的客户端等）的出现，瘦客户机程序对这些应用就显得无能为力了。
因此，富客户机程序的需求变得越来越强烈，但是其本身固有的部署和维护问题怎么解决呢？Eclipse 3.x版本的RCP（详细内容参见本书的第17章）为富客户机程序提供全新的解决方案，它充分利用Ecli
pse插件化的的特点，彻底地将集成开发环境相关的依赖项从Eclipse平台底层剥离，同时更多的用户界面组件被开放并允许个性化的定制。采用基于OSGi（Open Service Gateway Initiative）的平台运行时，从而实现动态的插件安装、移除和升级机制。3.x
版本具有的以下特性解决了富客户机程序所固有的问题。
1．组件化
Eclipse包含了一套健壮的组件模型，基于Eclipse的系统通过组合这些称之为“插件”的组件来实现自身功能。插件是有版本编号的，可以在多个应用中共享，相同插件的多个版本可以
并行安装，通过配置，来运行其所指定的版本，通过添加或者替换组件可以实现应用的不断完善和扩充。
2．基础设施
组件模型之上是一套框架和工具，用于帮助实现客户端应用的开发，提供可以扩展的用户界面规范，帮助支持、上下文敏感帮助、网络升级、错误控制等。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。