纳米盘下载
27 六月 2008
单词Mp3随身宝源码分享
前两天联系了令狐虫，收藏了他的单词MP3随身宝源码（名字太长了，实际上就像一个Java版的金山词霸）。自己学习研究了下，并且把相应的注释补全（汗一个！令狐同志不写注释害苦了我这个Java初学者）。感兴趣的朋友可以联系令狐虫，或者从我这里直接下载（因为有词库数据和语音数据，所以比较大，我正在上传到网盘）。
纳米盘下载
纳米盘下载
23 六月 2008
JSP中的pageEncoding和contentType属性区别
转：http://www.webjx.com/htmldata/2007-09-27/1190856301.html
关于JSP页面中的pageEncoding和contentType两种属性的区别：
pageEncoding是jsp文件本身的编码
contentType的charset是指服务器发送给客户端时的内容编码
JSP要经过两次的“编码”，第一阶段会用pageEncoding，第二阶段会用utf-8至utf-8，第三阶段就是由Tomcat出来的网页， 用的是contentType。
第一阶段是jsp编译成.java，它会根据pageEncoding的设定读取jsp，结果是由指定的编码方案翻译成统一的UTF-8 JAVA源码（即.java），如果pageEncoding设定错了，或没有设定，出来的就是中文乱码。
第二阶段是由JAVAC的JAVA源码至java byteCode的编译，不论JSP编写时候用的是什么编码方案，经过这个阶段的结果全部是UTF-8的encoding的java源码。
JAVAC用UTF-8的encoding读取java源码，编译成UTF-8 encoding的二进制码（即.class），这是JVM对常数字串在二进制码（java encoding）内表达的规范。
第三阶段是Tomcat（或其的application container）载入和执行阶段二的来的JAVA二进制码，输出的结果，也就是在客户端见到的，这时隐藏在阶段一和阶段二的参数contentType就发挥了功效
contentType的設定.
pageEncoding 和contentType的预设都是 ISO8859-1. 而随便设定了其中一个, 另一个就跟着一样了(TOMCAT4.1.27是如此). 但这不是绝对的, 这要看各自JSPC的处理方式. 而pageEncoding不等于contentType, 更有利亚洲区的文字 CJKV系JSP网页的开发和展示, (例pageEncoding=GB2312 不等于 contentType=utf-8)。
jsp文件不像.java，.java在被编译器读入的时候默认采用的是操作系统所设定的locale所对应的编码，比如中国大陆就是GBK，台湾 就是BIG5或者MS950。而一般我们不管是在记事本还是在ue中写代码，如果没有经过特别转码的话，写出来的都是本地编码格式的内容。所以编译器采用 的方法刚好可以让虚拟机得到正确的资料。
但是jsp文件不是这样，它没有这个默认转码过程，但是指定了pageEncoding就可以实现正确转码了。
举个例子:
<%@ page contentType="text/html;charset=utf-8" %>
大都会打印出乱码，因为输入的“你好”是gbk的，但是服务器是否正确抓到“你好”不得而知。
但是如果更改为
<%@ page contentType="text/html;charset=utf-8" pageEncoding="GBK"%>
这样就服务器一定会是正确抓到“你好”了。
22 六月 2008
（转的）使用Eclipse打JAR包
To create a new JAR file in the workbench:
- In the Package Explorer, you can optionally pre-select one or more Java elements to export. (These will be automatically selected in the JAR Package Specification wizard page, described in Step 4.)
- From the menu bar, select File > Export.
- Select JAR file, then click Next.
- In the Jar Package Specification page, select the resources that you want to export in the Select the resources to export field.
- Select the appropriate check box to specify whether you want to Export generated class files and resources or Export Java source files and resources.Note: Selected resources are exported in both cases.
- In the Select the export destination field, either type or click Browse to select a location for the JAR file.
- Select or clear the Compress the contents of the JAR file check box.
- Select or clear the Overwrite existing files without warning check box. If you clear thischeck box, then you will be prompted to confirm the replacement of each file that will be overwritten.Note: The overwrite option is applied when writing the JAR file, the JAR description, and the manifest file.
- You have two options:
- Click Finish to create the JAR file immediately.
- Click Next to use the JAR Packaging Options page to set advanced options, create a JAR description, or change the default manifest.
（还是NetBeans方便，没这么多麻烦事。当然，高人直接使用jar命令手动打包了。）
19 六月 2008
使用Eclipse平台共享代码
原文地址：http://www.ibm.com/developerworks/cn/linux/opensource/os-ecshare/index.html
在团队项目中共享源代码
现今的大多数应用程序是由多人组成的团队开发的。即使只涉及几个开发人员的小项目，也需要对源代码的更改进行严格控制。这就是源代码管理软件的任务。 源代码版本控制软件必须支持两个核心功能：
当 团队成员完成新的工作时，通过将这些更改提交到资源库来共享他们的工作。类似地，当他们希望获得最新可用的工作成果时，就可以根据资源库中的更改，更新自 己的本地工作空间。这意味着项目资源库会因团队成员提交新工作成果而经常发生更改。换句话说，资源库应该表示项目的当前状态。任何时候，团队成员都要能够 根据资源库更新自己的工作空间，并确信它们是最新的。
维护历史记录也很重要，那样就可以将当前工作与先前版本进行比较，如有必要，还可以回复到先前版本。协调团队的工作，以便只存在唯一的当前项目状态定义，以及包含团队已集成的工作，这些对于管理版本控制也是十分必要的。这种协调有可能是最难实现的目标。
最 理想的模型是：团队的任何成员都可以对自己有权访问的任何资源进行更改。因为两个团队成员可以提交对同一资源的更改，所以有可能发生冲突，必须解决这种冲 突。这种模型假定冲突具有唯一性。但遗憾的是，没有任何源代码是孤立地存在的；通常它包含与其它资源隐式或显式的相关性。源代码引用了在其它源代码资源中 描述的构件。但源代码管理软件的工作就到此为止了，因为它并不能取代项目管理。项目管理者必须履行其职责：协调其它成员的工作以及负责进度、项目阶段和发 布日期。此外，源代码管理也不能替代开发人员之间的交流。
Eclipse 平台如何支持代码管理
Eclipse 平台提供了作为团队在软件项目中共享代码和工作的能力。Eclipse 广泛地支持各种代码管理解决方案，这要归功于它的插件体系结构（不过，现已推出了对 CVS 的支持）。Eclipse 平台体系结构的重点在于 工作空间。工作空间维护构建和测试软件项目所需的一切。它包含对象（源代码和资源）。 它还保存了用于项目、IDE 和插件的配置设置。工作空间是在开发人员的机器上本地进行维护的，而团队通过外部资源库进行协作，不同开发人员的代码在资源库进行汇集。可以经由因特网通过“客户机-服务器”体系结构访问资源库。
Eclipse 平台提供了对于直接从工作空间进行团队开发操作的支持。这种支持允许开发人员并发地与几个独立的资源库以及不同版本的代码或项目进行交互。工作空间中的资 源允许团队支持组件处理版本和配置管理问题。当然，单个工作空间可以同时访问不同类型的资源库。Eclipse 平台并没有提供它自己的代码管理解决方案；它总是依靠外部系统。Eclipse 平台只对一个（但也是最流行的一个）源代码管理系统提供内置支持：并发版本控制系统（Concurrent Versions System，CVS）。 对第三方代码管理应用程序的支持一节中描述了使用第三方插件支持其它资源库。
CVS 是什么？
CVS 诞生于 1986 年，当时作为一组 shell 脚本而出现，但它现在已经发展成了最流行的针对软件开发人员的源代码版本管理解决方案。CVS 是用于代码版本管理的开放源码的客户机／服务器解决方案，它可用于各种平台，包括 Linux 和 Windows NT/2000/XP。请参阅本文末尾的 参考资料，其中有 CVS 客户机、服务器和源代码的下载链接。
通常，CVS 的主要功能是记录源文件的历史。当一组开发人员从事同一个项目时，CVS 将他们彼此隔离开来。每个开发人员都在他／她自己的目录中独立工作，然后使用 CVS 资源库（不时地）合并工作结果。
Eclipse 拥有与 Eclipse 平台 IDE 紧密集成的内置 CVS 客户机，它是作为一个单独透视图（CVS Repository Exploring 透视图）而实现的，用于与 CVS 的交互。用于 CVS 的通用 Eclipse 设置（General Eclipse settings for CVS）位于 Window -> Preferences window -> Team下。在切换到 CVS Repository Exploring 透视图之后，就可以使用所有 CVS 操作了（转至 Window -> Open Perspective -> Other -> CVS Repository Exploring菜单 — 请参阅 图 1和 图 2）。
图 1. 切换到 CVS Repository Exploring 透视图
首先设置资源库的位置，它将定义用于选定 CVS 服务器／资源库的连接参数。请确保使用 SSH 隧道（
图 2. 浏览 CVS Repository Exploring 透视图中的 CVS 资源库
Eclipse/CVS 的源代码工作流
在 CVS 团队协作模型中，团队成员彼此独立地在他们各自的工作台上完成自己的所有工作。最后，他们希望共享其工作。他们通过 CVS 资源库实现这一点。CVS 使用分支（branch）模型来支持彼此独立而又高度相互依赖的多个工作流程（course of work）。这些分支是开发团队用来共享和集成正在进行中的工作的地方。可以认为 分支是一个共享的工作台，当团队成员对源代码进行更改时就更新这个工作台。这个模型允许从事 CVS 团队项目的每个开发人员在进行更改时与其他成员共享其工作，以及在项目进展期间访问其他成员的工作。
一个称为 HEAD的特殊分支用来表示资源库中的主要工作流程（HEAD 通常被称为 主干）。当团队成员将资源提交给该分支时，会影响这些相关性。 确保相关性的完整性是很重要的，因为该分支表示了当前项目的状态。当然，任何时候，团队成员都可以使用该分支的内容作为新工作的基础。
那些规则不仅适用于 CVS：无论使用哪种版本控制软件，团队项目中都有一些用于源代码管理的常见步骤。下面是一个使用 Eclipse 内置的 CVS 支持的示例工作流：
1. 启动新的团队项目
每个新的空 Eclipse 项目都可以通过 CVS（或受支持的任何其它源代码管理系统）进行共享。开发人员也可以通过将其现有的代码迁移到资源库来共享它。要进行共享，单击项目主文件夹，在显示的上下文菜单中使用 Team -> Share Project选项，如 图 3所示。
图 3. 使用 CVS 资源库共享本地项目
另一个选项是通过从选定的 CVS 资源库分支导入代码来创建新的工作台项目。只要选择适当分支（或 HEAD），然后选择从 CVS Repository Exploring 透视图中的上下文菜单中选择“Checkout As Project”选项，如 图 4所示。
图 4. 从现有的 CVS 资源库创建新项目
2. 使用代码并进行更改
开发人员通过 Eclipse 工作台在本地使用代码，包括的工作有创建新资源、修改现有资源、编写注释，并在他们使用后在本地保存这些内容。
3. 使本地更改与 CVS 资源库同步
如果一个项目开发人员准备提交他／她的工作，那么首先要执行更新操作。这会针对引入的更改核对资源库，并将这些更改添加到该开发人员的本地工作台。这样确保了开发人员知道这些更改可能会影响他／她将要提交的工作的完整性。使用项目上下文菜单中的 Compare With...选项将本地版本与资源库中存储的代码进行比较（请参阅 图 5）。
图 5. 比较本地版本与资源库中的版本
下一步是解决最后出现的任何冲突，并设法再次编译代码。如果一切正常，那么从项目上下文菜单使用 Team -> Commit...选项执行提交操作，如 图 6所示。这会使所有更改都集成到资源库中。
图 6. 将更改提交到远程资源库
4. 管理资源库
CVS 允许开发人员将更改隔离在开发的某些独立路径之内，这些路径称为分支。当一个开发人员更改某个分支上的文件时，这种更改不会出现在主干或其它分支上。 那些分支被命名为 子版本（subversion）或 代码分叉（code fork）。稍后，由合并操作将更改从一个分支迁移到另一个分支（或主干）。然后提交这些修订。这样就有效地将更改复制到了另一个分支上。使用项目上下文菜单的 Team -> Branch...选项，Eclipse 使开发分支之间的迁移变得容易。
当然，当开发团队维护大型资源库时，有必要控制项目内的提交和合并操作。Eclipse/CVS 集成提供了一种特殊的视图：CVS Repository History（请参阅 图 7）。它给出了关于团队成员在资源库中所执行更改的快速预览。
图 7. 在 CVS Resource History 窗口中查看带注释的修订历史记录
Eclipse 平台提供了几个支持代码管理的实用程序。最有用的是补丁功能。它将出自两个来源（譬如本地工作台和资源库）的代码进行比较，然后创建一个包含代码差异的类似 UNIX 的补丁文件（请参阅 图 8）。可以将该文件发送给开发人员以将源代码升级到最新版本。
图 8. 创建用于源代码分发的补丁
5. 断开项目与 CVS 的连接
当项目开发已经结束，并且团队希望 冻结源代码时，可以从 HEAD 资源库删除该项目的最终版本。断开项目与 CVS 的连接将在该项目及其资源上禁用资源库操作，并删除与该项目相关联的 CVS 信息（这一操作是可选的）。
可以通过项目上下文菜单中的 Team -> Disconnect选 项执行断开连接操作。通过选择这个选项，会打开 Confirm Disconnect from CVS 对话框。在将该项目与资源库的连接断开之后，该团队必须确定如何处理 CVS 信息。第一个选项是“Delete the CVS meta information”；它将禁用 CVS 团队菜单操作并从文件系统中删除 CVS 文件夹及其内容。第二个选项是“Do not delete the CVS meta information”；它将禁用 CVS 团队菜单操作，但保留 CVS 元信息。
对第三方代码管理应用程序的支持
CVS 有几个重要的限制：它不能确定单个文件或整个文件集范围内同时进行的更改，它也不能检测文件之间的逻辑冲突。其冲突概念纯粹是文本意义上的，当对于同一基 本文件的两个更改时间上非常非常接近，从而使合并命令受到干扰时，就会发生冲突。CVS 也不能提供任何类似于消息传递这样的交互式协作工具。幸运的是，CVS 并不是 Eclipse 平台所支持的唯一的源代码管理软件。 开发人员可以通过插件扩展 Eclipse 平台的功能，而且目前（到 2003 年 3 月 4 日为止）已有 16 个可用于团队开发软件的插件。所有插件都是由 Eclipse 社区或商业软件供应商创建的。这些插件中的大多数添加了对第三方、商业源代码管理系统的支持。最有价值的插件是那些支持流行的企业代码管理系统（如 Merant PVCS 和 Rational ClearCase）的插件。例如，CVS-SSH2 插件允许通过 SSH2 会话访问 CVS，而 Microsoft Visual SourceSafe（VSS）团队提供程序插件添加了对 MS VSS 产品的支持（也可以在诸如 Linux 这样的非 Windows 平台上使用）。
但是，我本人所偏爱的插件是 Koi（请参阅 参考资料以 获取链接）。尽管它并非严格用于源代码控制，但这个创新的工具给协作开发注入了许多新的活力。其当前版本支持工作台到工作台的消息传递、共享标记、冲突更 改通知、共享日历和事件通知。Koi 将 XML-RPC 用作其客户机-服务器体系结构中的通信模型。客户机是与“协作服务器”通信的单个 Eclipse 平台实例，而协作服务器也是一个 Eclipse 插件。Koi 使用以 JDBC 访问的关系数据库作为数据存储。可在 参考资料中找到指向完整的、经过分类的 Eclipse 插件注册表的链接。
参考资料
关于作者
本文概述了 Eclipse 平台如何支持软件项目中的源代码版本控制。首先，我们将简要讨论一下团队代码开发的思想，然后研究 Eclipse 如何使用 CVS 代码资源库。我们还将研究一些源代码管理软件工具，可以通过 Eclipse 插件扩展来支持这些工具。
在团队项目中共享源代码
现今的大多数应用程序是由多人组成的团队开发的。即使只涉及几个开发人员的小项目，也需要对源代码的更改进行严格控制。这就是源代码管理软件的任务。 源代码版本控制软件必须支持两个核心功能：
- 提供一种方法，能够协调对源代码的更改，并能集成这些更改
- 团队所提交工作的历史记录
当 团队成员完成新的工作时，通过将这些更改提交到资源库来共享他们的工作。类似地，当他们希望获得最新可用的工作成果时，就可以根据资源库中的更改，更新自 己的本地工作空间。这意味着项目资源库会因团队成员提交新工作成果而经常发生更改。换句话说，资源库应该表示项目的当前状态。任何时候，团队成员都要能够 根据资源库更新自己的工作空间，并确信它们是最新的。
维护历史记录也很重要，那样就可以将当前工作与先前版本进行比较，如有必要，还可以回复到先前版本。协调团队的工作，以便只存在唯一的当前项目状态定义，以及包含团队已集成的工作，这些对于管理版本控制也是十分必要的。这种协调有可能是最难实现的目标。
最 理想的模型是：团队的任何成员都可以对自己有权访问的任何资源进行更改。因为两个团队成员可以提交对同一资源的更改，所以有可能发生冲突，必须解决这种冲 突。这种模型假定冲突具有唯一性。但遗憾的是，没有任何源代码是孤立地存在的；通常它包含与其它资源隐式或显式的相关性。源代码引用了在其它源代码资源中 描述的构件。但源代码管理软件的工作就到此为止了，因为它并不能取代项目管理。项目管理者必须履行其职责：协调其它成员的工作以及负责进度、项目阶段和发 布日期。此外，源代码管理也不能替代开发人员之间的交流。
Eclipse 平台如何支持代码管理
Eclipse 平台提供了作为团队在软件项目中共享代码和工作的能力。Eclipse 广泛地支持各种代码管理解决方案，这要归功于它的插件体系结构（不过，现已推出了对 CVS 的支持）。Eclipse 平台体系结构的重点在于 工作空间。工作空间维护构建和测试软件项目所需的一切。它包含对象（源代码和资源）。 它还保存了用于项目、IDE 和插件的配置设置。工作空间是在开发人员的机器上本地进行维护的，而团队通过外部资源库进行协作，不同开发人员的代码在资源库进行汇集。可以经由因特网通过“客户机-服务器”体系结构访问资源库。
Eclipse 平台提供了对于直接从工作空间进行团队开发操作的支持。这种支持允许开发人员并发地与几个独立的资源库以及不同版本的代码或项目进行交互。工作空间中的资 源允许团队支持组件处理版本和配置管理问题。当然，单个工作空间可以同时访问不同类型的资源库。Eclipse 平台并没有提供它自己的代码管理解决方案；它总是依靠外部系统。Eclipse 平台只对一个（但也是最流行的一个）源代码管理系统提供内置支持：并发版本控制系统（Concurrent Versions System，CVS）。 对第三方代码管理应用程序的支持一节中描述了使用第三方插件支持其它资源库。
  |
CVS 是什么？
CVS 诞生于 1986 年，当时作为一组 shell 脚本而出现，但它现在已经发展成了最流行的针对软件开发人员的源代码版本管理解决方案。CVS 是用于代码版本管理的开放源码的客户机／服务器解决方案，它可用于各种平台，包括 Linux 和 Windows NT/2000/XP。请参阅本文末尾的 参考资料，其中有 CVS 客户机、服务器和源代码的下载链接。
通常，CVS 的主要功能是记录源文件的历史。当一组开发人员从事同一个项目时，CVS 将他们彼此隔离开来。每个开发人员都在他／她自己的目录中独立工作，然后使用 CVS 资源库（不时地）合并工作结果。
Eclipse 拥有与 Eclipse 平台 IDE 紧密集成的内置 CVS 客户机，它是作为一个单独透视图（CVS Repository Exploring 透视图）而实现的，用于与 CVS 的交互。用于 CVS 的通用 Eclipse 设置（General Eclipse settings for CVS）位于 Window -> Preferences window -> Team下。在切换到 CVS Repository Exploring 透视图之后，就可以使用所有 CVS 操作了（转至 Window -> Open Perspective -> Other -> CVS Repository Exploring菜单 — 请参阅 图 1和 图 2）。
图 1. 切换到 CVS Repository Exploring 透视图
首先设置资源库的位置，它将定义用于选定 CVS 服务器／资源库的连接参数。请确保使用 SSH 隧道（
extssh ）。图 2. 浏览 CVS Repository Exploring 透视图中的 CVS 资源库
|
|
Eclipse/CVS 的源代码工作流
在 CVS 团队协作模型中，团队成员彼此独立地在他们各自的工作台上完成自己的所有工作。最后，他们希望共享其工作。他们通过 CVS 资源库实现这一点。CVS 使用分支（branch）模型来支持彼此独立而又高度相互依赖的多个工作流程（course of work）。这些分支是开发团队用来共享和集成正在进行中的工作的地方。可以认为 分支是一个共享的工作台，当团队成员对源代码进行更改时就更新这个工作台。这个模型允许从事 CVS 团队项目的每个开发人员在进行更改时与其他成员共享其工作，以及在项目进展期间访问其他成员的工作。
一个称为 HEAD的特殊分支用来表示资源库中的主要工作流程（HEAD 通常被称为 主干）。当团队成员将资源提交给该分支时，会影响这些相关性。 确保相关性的完整性是很重要的，因为该分支表示了当前项目的状态。当然，任何时候，团队成员都可以使用该分支的内容作为新工作的基础。
那些规则不仅适用于 CVS：无论使用哪种版本控制软件，团队项目中都有一些用于源代码管理的常见步骤。下面是一个使用 Eclipse 内置的 CVS 支持的示例工作流：
1. 启动新的团队项目
每个新的空 Eclipse 项目都可以通过 CVS（或受支持的任何其它源代码管理系统）进行共享。开发人员也可以通过将其现有的代码迁移到资源库来共享它。要进行共享，单击项目主文件夹，在显示的上下文菜单中使用 Team -> Share Project选项，如 图 3所示。
图 3. 使用 CVS 资源库共享本地项目
另一个选项是通过从选定的 CVS 资源库分支导入代码来创建新的工作台项目。只要选择适当分支（或 HEAD），然后选择从 CVS Repository Exploring 透视图中的上下文菜单中选择“Checkout As Project”选项，如 图 4所示。
图 4. 从现有的 CVS 资源库创建新项目
2. 使用代码并进行更改
开发人员通过 Eclipse 工作台在本地使用代码，包括的工作有创建新资源、修改现有资源、编写注释，并在他们使用后在本地保存这些内容。
3. 使本地更改与 CVS 资源库同步
如果一个项目开发人员准备提交他／她的工作，那么首先要执行更新操作。这会针对引入的更改核对资源库，并将这些更改添加到该开发人员的本地工作台。这样确保了开发人员知道这些更改可能会影响他／她将要提交的工作的完整性。使用项目上下文菜单中的 Compare With...选项将本地版本与资源库中存储的代码进行比较（请参阅 图 5）。
图 5. 比较本地版本与资源库中的版本
下一步是解决最后出现的任何冲突，并设法再次编译代码。如果一切正常，那么从项目上下文菜单使用 Team -> Commit...选项执行提交操作，如 图 6所示。这会使所有更改都集成到资源库中。
图 6. 将更改提交到远程资源库
4. 管理资源库
CVS 允许开发人员将更改隔离在开发的某些独立路径之内，这些路径称为分支。当一个开发人员更改某个分支上的文件时，这种更改不会出现在主干或其它分支上。 那些分支被命名为 子版本（subversion）或 代码分叉（code fork）。稍后，由合并操作将更改从一个分支迁移到另一个分支（或主干）。然后提交这些修订。这样就有效地将更改复制到了另一个分支上。使用项目上下文菜单的 Team -> Branch...选项，Eclipse 使开发分支之间的迁移变得容易。
当然，当开发团队维护大型资源库时，有必要控制项目内的提交和合并操作。Eclipse/CVS 集成提供了一种特殊的视图：CVS Repository History（请参阅 图 7）。它给出了关于团队成员在资源库中所执行更改的快速预览。
图 7. 在 CVS Resource History 窗口中查看带注释的修订历史记录
Eclipse 平台提供了几个支持代码管理的实用程序。最有用的是补丁功能。它将出自两个来源（譬如本地工作台和资源库）的代码进行比较，然后创建一个包含代码差异的类似 UNIX 的补丁文件（请参阅 图 8）。可以将该文件发送给开发人员以将源代码升级到最新版本。
图 8. 创建用于源代码分发的补丁
5. 断开项目与 CVS 的连接
当项目开发已经结束，并且团队希望 冻结源代码时，可以从 HEAD 资源库删除该项目的最终版本。断开项目与 CVS 的连接将在该项目及其资源上禁用资源库操作，并删除与该项目相关联的 CVS 信息（这一操作是可选的）。
可以通过项目上下文菜单中的 Team -> Disconnect选 项执行断开连接操作。通过选择这个选项，会打开 Confirm Disconnect from CVS 对话框。在将该项目与资源库的连接断开之后，该团队必须确定如何处理 CVS 信息。第一个选项是“Delete the CVS meta information”；它将禁用 CVS 团队菜单操作并从文件系统中删除 CVS 文件夹及其内容。第二个选项是“Do not delete the CVS meta information”；它将禁用 CVS 团队菜单操作，但保留 CVS 元信息。
|
对第三方代码管理应用程序的支持
CVS 有几个重要的限制：它不能确定单个文件或整个文件集范围内同时进行的更改，它也不能检测文件之间的逻辑冲突。其冲突概念纯粹是文本意义上的，当对于同一基 本文件的两个更改时间上非常非常接近，从而使合并命令受到干扰时，就会发生冲突。CVS 也不能提供任何类似于消息传递这样的交互式协作工具。幸运的是，CVS 并不是 Eclipse 平台所支持的唯一的源代码管理软件。 开发人员可以通过插件扩展 Eclipse 平台的功能，而且目前（到 2003 年 3 月 4 日为止）已有 16 个可用于团队开发软件的插件。所有插件都是由 Eclipse 社区或商业软件供应商创建的。这些插件中的大多数添加了对第三方、商业源代码管理系统的支持。最有价值的插件是那些支持流行的企业代码管理系统（如 Merant PVCS 和 Rational ClearCase）的插件。例如，CVS-SSH2 插件允许通过 SSH2 会话访问 CVS，而 Microsoft Visual SourceSafe（VSS）团队提供程序插件添加了对 MS VSS 产品的支持（也可以在诸如 Linux 这样的非 Windows 平台上使用）。
但是，我本人所偏爱的插件是 Koi（请参阅 参考资料以 获取链接）。尽管它并非严格用于源代码控制，但这个创新的工具给协作开发注入了许多新的活力。其当前版本支持工作台到工作台的消息传递、共享标记、冲突更 改通知、共享日历和事件通知。Koi 将 XML-RPC 用作其客户机-服务器体系结构中的通信模型。客户机是与“协作服务器”通信的单个 Eclipse 平台实例，而协作服务器也是一个 Eclipse 插件。Koi 使用以 JDBC 访问的关系数据库作为数据存储。可在 参考资料中找到指向完整的、经过分类的 Eclipse 插件注册表的链接。
参考资料
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
- 请参加 eclipse.org上 的 Eclipse 平台社区。Eclipse 平台源代码遵循 Common Public License。Eclipse.org 还有一个 Eclipse 项目的术语和描述词汇表，以及技术文章和新闻组。Eclipse 平台白皮书（可在 Eclipse.org 主页获取）详细描述了 Eclipse 的主要组件和功能。
- 从 eclipse.org 下载 KOI 插件。
- 查看 Eclipse 插件的完整的、经过分类的注册表。
- 从 CVS 主页或 LORIA 站点下载 CVS 客户机、服务器和源代码。
- 请参阅 developerWorks文章“ Working the Eclipse Platform”，以了解关于 Eclipse 平台的背景知识。
- 请参阅 developerWorks文章“ Getting started with the Eclipse Platform”，这篇文章介绍了用 Eclipse 平台以及使用 Eclipse 插件编辑、编译和调试应用程序。
- 请参阅 developerWorks文章“ 开发 Eclipse 插件”，这篇文章介绍了如何开发 Eclipse 插件。
- 从 developerWorks的这些文章中获取关于 Eclipse 的更多信息：
- 在 developerWorks开放源码项目专区查找 更多有关 Eclipse 和开放源码参考资料。
关于作者
| Pawel Leszek 是 Studio B 的一位作家， 他是一位专长于 Linux/Win/Mac OS 系统体系结构和管理的独立软件顾问和作家。他具有许多操作系统、编程语言和网络协议方面的经验， 尤其是 Lotus Domino 和 DB2 方面的经验。Pawel 还是 LinuxWorld上一系列文章的作者，以及 PC World波兰版的 Linux 专栏作家。Pawel 和他的妻子以及可爱的小女儿住在华沙。欢迎提问并提出意见；您可以直接给作者发电子邮件（ pawel.leszek@ipgate.pl）。 | |
13 六月 2008
11 六月 2008
订阅：
博文 (Atom)