主题：【原创】开源的Eclipse（一） Eclipse的历史 -- 可爱的中国
家园 Eclipse built-in Ant确实很实用。 还有Eclipse的CDT，很好用，Borland和Eclipse比根本不是一个档次的IDE。
其实这些模块你可以用也可以不用，比如Tomcat你就可以选择在Eclipse里面装，或者在外面另外装也可以，listening port对了就行了。这些模块没有什么非用不可的地方。
家园 问题不是出在选装功能上 主要的问题是，为了把Eclipse变成一个开发平台，而不是IDE，在底层增加了很多额外的功能，比如OSGi的导入。 3.x 之前是不用OSGi的。 这样对应单纯的IDE而言未必是好处，带来了额外的开销和复杂性。比如内存的占用，性能变差，额外的Bug等等。而且相对而言，对IDE本身的关注程度也会下降。
我曾经比较过2.x 和 3.x， 2.x 的速度那是象飞一样的快。 但是作为一个应用开发的平台，Eclipse确实带来了很多好处，降低了开发的门槛，以后我还会具体的谈到，如果我不学萨坑的话。
家园 【原创】开源的Eclipse 二 Eclipse有什么用 Eclipse的起源是一个IDE， 所以显而易见，他是一个Java开发工具。但是说实话，我觉的2.x的Eclipse是一个很好的IDE, 3.0以后呢就不那么好了，内存吃的厉害，也不够稳定，功能多而不实用。
那么，Eclipse的价值何在呢？ 其实，我以为Eclipse的最大价值在于它为其他开发公司提供了一个商业友好的，功能齐全的，开源的开发平台。而这三个要素是Eclipse成功的主要原因。
第一，Eclipse的EPL协议是一个商业友好的协议。 EPL1.0 http://www.eclipse.org/legal/epl-v10.html 协议实际上允许用户自由的使用基于EPL的二进制程序，或者源码。除了要求用户必须保留原有的版权信息和一份EPL协议拷贝外，没有其他特别的限制。 也就是说，你可以把Eclipse 程序包含在你的产品中，也可以直接Copy Eclipse 的源代码并修改它，并把他集成到你的产品中去。而这个产品可以是开源的，也可以是商用的。 因此这就保证了Eclipse对商业公司有足够的吸引力。
第二，Eclipse 同时又提供了足够的功能来让你在他的基础上进行开发。
Eclipse 的基本功能划大致包括。
1. Eclipse Rich Client 平台
* Equinox OSGi – 这是一个符合OSGI的实现，它提供基础的资源生命周期的管理。
* Core platform – 负责启动和运行基础的Eclipse 服务。
* Standard Widget AWT 的对应物， 体统基础的界面功能，包括对话框，按钮等基础的界面组件。 SWT是和平台的组件一对一对应的，所以是依赖平台的。
* JFace – 对SWT的MVC 封装，文字处理，标准编辑器等功能。
* Eclipse Workbench – 提供Eclipse 标准界面。
2. 各种语言开发工具
* JDT － Java
* CDT － C/C++
* PDT － PHP
* ATF - Ajax
* ...
3. 针对具体应用的工具
* BIRT － 报表开发
* DTP － 数据库访问连接
* WTP － Java Web 开发
* TPTP － 测试和调试工具
* SOA Tools
* EMF － 自动模型生成
* GEF － 图形编辑界面框架
* DSDP － 嵌入开发
有了上述的这些丰富的功能，商业公司就没有必要再编写基础性的功能（实际上大多数公司来写的话，未必达的到Eclipse的水平。有几个能牛过IBM?），而是在Eclipse 的基础上扩展来提供专有的功能。 比如IBM Webshpere studio, Lotus, Actuate 的商业报表工具，Sybase 的继承开发环境，还有很多很多的商业产品都是基于Eclipse 平台扩展开发的。
第三，Eclipse 是开源的
作为开发人员一直面对的一个问题就是没有合适的文档。 特别是在使用第三方的平台的时候，经常会应为找不到文档和合适的运行范例而发愁。特别是在使用面向OO的API的时候，由于有大量的回调等功能，要正确的使用某些功能实在不是一个简单的任务。 而开源的Eclipse 带来的好处是，Eclipse 源代码本身就是最好的文档和例子。
另一个问题是虫虫。 使用一个商用的第三方平台的用户在遇到虫虫时，出了和提供商协商之外，别无他法。 而Eclipse 的开源特色使得用户可以自己杀虫， 并把补丁提交给Eclipse社区，这样对用户来说就拥有了足够的灵活性。
看上去不错，免费的馅饼，味道还好，还管够，共产主义终于实现了？ 万恶的资本家是不会放弃对利润的无限追求的。
快看铁牛吃太阳啦
家园 我去下载了个php的 安装了，运行了，发现的确是比以前的版本要舒服一些，但是似乎不支持中文。程序中的中文字符全乱码了。
家园 【原创】补 OSGi是什么 OSGi是Open Service Gateway Initiative的简称。
OSGi是一种服务运行平台。通过实现能够提供服务的符合OSGi规范的组件，用户可以将其组件发布到OSGi运行平台，供用户和其他组件使用。Eclipse equinox 是OSGi 规范的一种实现。Eclipse Plug-in的管理都是基于OSGi的。
OSGi规范的核心组件是OSGi框架。这个框架为应用程序（被叫做组件（bundle））提供了一个标准环境。整个框架可以划分为一些层次：
* L0: 运行环境
* L1: 模块
* L2: 生命周期管理
* L3: 服务注册
L0 层执行环境是Java环境的规范。
L1 模块层定义类的装载策略。
L2 生命周期层增加了能够被动态安装、开启、关闭、更新和卸载的bundles。
L3 层增加了服务注册。服务注册提供了一个面向bundles的动态性的协作模型。
References: China OSGi User Group http://china.osgiusers.org/Main/Technology
关键词(Tags): #Eclipse，家园 【原创】补二 OSGi是什么 呵呵，原来是不准备多说OSGi，因为这个是Eclipse 很底层的东西。下面有人提意见了，那我就试着举个例子吧，希望有所帮助。
比如出过国的人大多遇到一个问题，就是你带出去／回来的电器没法直接插在电源插座上，因为不同国家的电源插座的标准和交流电的电压标准是不一样的。
OSGi 的运行环境就类似与供电系统，提供组件（bundle）可以运行的平台。
OSGi 模块管理就是类似的这么一个插座／电压标准，这样就可以保证所有的符合标准的组件（bundle）都可以插入到OSGi的运行平台上并能够运行。
可是呢电器插到插座里了，并不一定马上通电用， 而是一般需要一个开关来控制电器的运行。
OSGi的生命周期管理就是提供这么一个类似的功能，当组件需要运行的时候，这个层面负责装载和启动这个组件，而当组件不需要运行是负责卸载这个组件来减小系统的负担和资源占用。
OSGi服管理类似智能家电的通讯协议， 允许组件提供出了基础的生命周期管理之外的更复杂的通讯协作功能。
大概就是这样的，喝水看铁牛吃太阳去。
家园 【原创】再补， Equinox 和 OSGi 一些关于Equinox（Eclipse 的OSGi项目）的基本情况。
OSGi 是OSGi Alliance 定义的一套Java标准，具体见前文，或者访问www.osgi.org。其最早的版本开始于1998 年，目前最新的标准是OSGi R4 core framework specification。它的最初的目的是为了智能家电市场。 有什么联想么？ 对了， Java 的目的好像也是这个。看里家电也是一个很有前途的职业。OSGi Alliance 只负责定义标准，而不提供具体的实现。
目前被OSGi Alliance推荐的实现包括Apache Felix，Eclipse Equinox和Knopflerfish。
Equinox 是一个被OSGi Alliance认证的基于OSGi R4 core framework 标准的实现。
Equinox 为Eclipse提供了一套OSGi 框架标准实现,这包括
* 对 OSGi 标准的实现 （EEG, MEG 和 VEG ）
* 对OSGi 标准的研究扩展和纠错。
* 提供部分OSGi标准没有的扩展功能。
* 实现Eclipse 其他项目需要的基本功能。
因此，所有的Eclipse 其他项目都是构建在Equinox项目之上的，它是Eclipse 得以运行的基础。 同时，Equinox 也可以单独运行，作为一个OSGi的实现平台提供符合OSGi标准的服务。应此你也可以把Equinox作为你的服务器应用的基础平台整合到你的项目里去。
IBM的野心也就很明白了，IBM 看来是准备在桌面和服务器端利用Eclipse Logo 一统江湖，千秋万代。至于能不能实现，就要走着瞧了。
喝水看铁牛
关键词(Tags): #Eclipse，家园 事实上eclipse的精华就是osgi osgi可以走得远远超过eclipse可以达到的地步。
它不仅是种模块化的部署模型，也是一种模块化的运行时环境。
它的特点应该是，粒度位于组件和应用程序之间。
此外包之间强大的依赖管理和动态的卸载、装载能力，如果还加上eclipse的扩展点机制。
作为部署和运行环境应该是比较完美了。
顺便说一句，现在很多应用服务器也采用osgi技术。
家园 Equinox是OSGi的扩展 OSGi是基于SOA架构的，而Equinox是基于扩展点架构的，并不是纯正的OSGi血统。要看纯正的OSGi，还是要去用Apache的Felix和基于其之上的ServiceMix
家园 说实话osgi过分复杂了 bundle和bundle之间的关系太复杂了，关是一个classpath就绕晕了无数人。
当初我曾经想用osgi构建我们的系统底层framework，后来觉得恐怕做出来也难维护，懂osgi的人太少了。
家园 你可以试一下Spring DM Spring在OSGi上面也下了很大的赌注，甚至专门建了一个OSGi bundle的maven repository。当然OSGi bundle的maven plugin也比以前改进很多了，也提供了不错的archetype。
简而言之，如果你对Spring熟悉的话，从Spring DM上手会很快。