页面内容

工作区准则

这些准则阐明了与 GlassFish 工作区相关的过程。如果您在工作区上进行工作，请确保熟悉这些准则。

跨模块协调

• 请使用模块所有者列表来传达可能会影响其他模块的更改。例如：
  • 更改其他模块所依赖的接口
  • 将组件升级至新的主要版本，例如，从 Ant 1.4.1 升级至 1.5 以及从 EJB API 2.0 升级至 2.1
• 在返回之前，需要确保可以构建完整的工作区。如果对多个模块所依赖的接口进行了更改，则做到这一点尤为重要。

受保护的模块

• 如果没有获得明确的批准，不得修改模块 glassfish 和 bootstrap。如果需要修改这些模块，请发送电子邮件至 dev@glassfish.dev.java.net。请提供简要说明和 CVS 差异。

二进制相关项

• 请避免将任何二进制文件（尤其是 JAR 文件）签入到工作区。我们希望避免在工作区中出现同一 JAR 文件的多个版本。
• 如果需要添加二进制相关项，请发送电子邮件至 dev@glassfish.dev.java.net。您需要提供二进制文件的正式发行版或提升版本 (promoted build) 的 URL 以及二进制文件的正式版本/内部版本号。它们将被复制到一个由发行工程进行管理的众所周知的位置，可供多个模块使用。

打包和 DTD 更改

如果需要进行以下操作，请发送电子邮件至 dev@glassfish.dev.java.net。

• 添加或更改您在最终产品映象中公开的文件。
• 对服务器配置 DTD 进行更��。请注意，任何更改可能都会要求对管理、CLI、GUI 进行更改。
• 更改特定于应用服务器的部署描述符 DTD。请注意，任何更改都可能要求对 DOL、部署工具和 Sun Java System Studio 进行更改。
  

日志记录准则

以下演示说明了在 GlassFish 中使用的日志记录准则。

编码约定

为 GlassFish 开发的所有代码必须遵循 Java 编码约定。

提交过程

所有每晚构建在太平洋标准时间晚上 12 点开始。请在大约从此时开始一小时的时间内停止提交，以便我们有时间签出源代码并在所有平台上开始构建。

一般签入过程

1. 由相应的工程师审阅您的代码
2. 如果您更改您的区域之外的代码，则必须与相应的模块所有者/技术负责人对这些更改进行讨论（请参见模块所有者列表）
   
3. 如果您仅更改了单个模块中的文件而没有删除文件，请执行以下操作
   • maven clobber
   • maven checkout bootstrap build
   • maven configure-runtime
4. 如果您删除或移动文件，或者修改多个模块中的代码，请执行以下操作
   • maven clobber
   • maven checkout bootstrap-all build
   • maven configure-runtime
5. 基于您的更改的范围和风险，运行一组适当的回归测试。在签入之前，您应确定一组正确的要运行的测试。对于某些签入，仅执行 quicklook 可能还不够。如有必要，请咨询您的模块所有者/技术负责人。以下测试为回归测试：
   • Quicklook 测试（所有签入的最低测试）
   • 开发者单元测试（强烈建议使用，对于某些团队而言是必需）
6. 在提交邮件中包含以下信息：
   • 描述（如果是错误修复，则还要包含错误号）
   • 代码审阅者
   • 已经运行了哪些测试
7. 确保对您的更改进行了全面的测试。考虑运行开发者单元测试。相应的 SQE 工程师是否知道这一更改？
8. 如果这是新的功能或对文档有影响，请发送电子邮件至文档团队。

软代码冻结期

• 目标是修复所有已安排要修复的发行版的所有错误（P1 和 P2 错误）。如果修复问题的风险太大，项目负责人也可以推迟修改错误。
• 除非项目负责人明确批准，否则不允许添加新功能。
  
• 所有签入必须由开发伙伴或模块所有者审阅并批准。
  
• 集成（ORB、JAX*、MQ等）必须由项目负责人批准，请发送电子邮件至 dev@glassfish.dev.java.net。

硬代码冻结期

• 这个时期的目标是仅修复“使人诧异的错误”。在软代码冻结期，应已修复了所有已知错误。
• 要使项目负责人考虑发行版中是否包含您所报告的错误，请发送电子邮件至 dev@glassfish.dev.java.net，并在主题行中写明 ShowStopper。
  
• 遵循与软代码冻结中相同的步骤，但仅修复非常重要的错误。
• 除了代码审阅之外，还要由项目负责人对签入进行批准
• 项目负责人每天都要作出响应，给出批准的错误修复和推迟的错误（延期到下一发行版）列表

代码审阅者核对表

1. 您是合适的审阅者吗？
2. 您能在一个工作日内审阅完代码吗？（如果不能，您能找到一个可以委托的人吗？）
3. 有记录过的错误吗（如果是错误修复）？
4. 是否对更改进行了全面的测试？
5. 代码中是否有足够的注释以便理解更改？
6. 代码是否符合国际化标准？
7. 是否所有错误都有日志消息？这些日志消息是否有消息 ID？这些日志消息的级别正确吗？这些日志消息的意思是否一目了然（即，含义不模糊）？日志消息是否会对性能产生严重影响？
8. 代码的格式与文件中其余代码的格式是否相同？是否遵循 Java 编码约定？
9. 设计是否合理？设计是否与模块其余部分的设计相适应？它是否足够强健？
10. 是否有其他需要调查的相关区域（可能需要相似的修复）？
    

代码提交者核对表

1. 有记录过的错误吗（如果是错误修复）？
2. 代码是否已经过审阅？
3. 是否已运行了所有合适的回归测试？
4. 是否向文档作者和测试者发送了关于更改的信息？
5. 是否对更改进行了全面的测试？应该编写新的单元测试吗？
6. 您的工作区最近更新了吗？您使用的分支正确吗？您已检查并解决了所有 CVS 冲突吗？
7. 代码中是否有足够的注释以便可以理解更改？
8. 代码是否符合国际化标准？
9. 是否所有错误都有日志消息？这些日志消息是否有消息 ID？这些日志消息的级别正确吗？这些日志消息的意思是否一目了然（即，含义不模糊）？该日志消息是否会对性能产生严重影响？
10. 代码的格式与文件中其余代码的格式是否相同？是否遵循 Java 编码约定？

审阅后/签入核对表

1. 您合并了所有请求的更改并使其经过审阅了吗？
2. 您是否已将所有新文件添加到系统信息库中？
3. 您是否更新、重新编译并运行了适当的测试？
4. 您是否一起签入了所有更改，并确保签入注释中包含描述、审阅者和运行的测试吗？如果更改涉及多个区域，建议还在日志消息中包含更改文件列表。
5. 如果更改是错误修复，则在 Bugtraq 中将问题更新至 integrated，并附带一个指向涉及该错误的单元测试或 Quicklook 测试的链接。
6. 如果更改影响到用户功能或正在妨碍用户功能的错误，则将更改通知给测试组、文档组和所有其他组。

Quicklook 测试

Quicklook 测试是广度测试，具有较高级别的涵盖范围，可涵盖应用服务器中的大量功能。Quicklook 测试旨在为开发者提供一种方法来测试应用服务器的主要功能并运行健全性检查，以确保没有破坏任何主要功能。

运行 Quicklook 测试：

1. 安装 GlassFish 或使用 maven bootstrap 或引导服务器映像 (${glassfish.home})，请参阅构建说明。
   
2. 签出 Quicklook 测试：在上一步中签出了 glassfish/bootstrap 模块之后，请使用 "checkout-quicklook" maven 目标签出 Quicklook 测试，以便仅签出少数几个运行 quicklook 测试所必需的文件，而不是整个 appserv-tests 模块。

cd 工作区（服务器代码所在的目录）
cd glassfish/bootstrap
maven checkout-quicklook

cvs -d :pserver:@cvs.dev.java.net:/cvs checkout glassfish/appserv-tests

setenv PATH $S1AS_HOME/bin;$JAVA_HOME/bin;$MAVEN_HOME/bin;$PATH

set PATH=%S1AS_HOME%/bin;%JAVA_HOME%/bin;%MAVEN_HOME%/bin;%PATH%

% cd $APS_HOME
% maven runtest

% cd $APS_HOME
% maven runtest-ee-standalone

% cd $APS_HOME
% maven runtest-ee

注意：

• 任何 build.xml 文件的默认目标都是 usage。运行 % ant 可以显示可能会独立执行的模块列表。
• 上面指定的 runtest 目标会启动一个 GlassFish 服务器实例和 Derby，并创建摘要报告。

模块所有者

如何编写文档注释

有关如何编写 Javadoc 注释的信息，请参见以下文档。

提交修补程序

说明详细且易于应用的修补程序对于遇到它并在它的帮助下使模块或组件更加稳定和强大的其他开发者来说，是很受欢迎的。提交修补程序的第一步是签署并返回 贡献者协议。请打印此表单，填写所有必要的详细信息并单击此处返回它。

• 如果您还不是 GlassFish 的成员，但是您可以访问邮件列表，则可以向该项目的开发者邮件列表发送有关您建议的修补程序的邮件。（阅读更多有关订阅项目邮件列表的信息。）
• 如果您是 GlassFish 成员，请首先查询 GlassFish 问题数据库，以确定该修补程序是否与已经报告的缺陷有关。
• 此外，还要查看 "Sun Java System Application Server/J2EE SDK" 类别下的 Web 错误
  。

如果您的修补程序与现有问题相关，则应在问题编辑屏幕中使用创建新的附件链接来提交您的修补程序，并使用添加注释部分发布说明性消息。（记住，对问题的更改会自动生成电子邮件，这些电子邮件将发送至问题的所有者和抄送列表上的任何人。所有这些人都将接受您的邮件以及指向您的修补程序的链接。）

如果不存在问题，则使用问题跟踪页面输入问题部分中的修补程序链接将您的修补程序作为新问题提交。请注意，您需要更新工作区以使用最新的源代码并重新构建 glassfish 服务器，此外，我们强烈建议您运行 Quicklook 测试来检查系统是否完好无损。然后根据此处的描述将您的修补程序文件附加到新问题：

1. 首先，确保您在最新版本的源文件中进行更改－为此，最好使用 CVS 来签出源文件（在 CVS trunk 上)，进行修改（但不将其签入），然后运行命令：

   cvs diff -c > mypatch

   获取源文件的上下文格式的修补程序。此操作将为您提供一个包含以下信息的修补程序文件：您正在修补的程序的版本、文件名和更改的内容。这是了解修补程序发展情况并使其他人易于找到并测试您的修补程序的首选方式。

2. 要应用修补程序，请转到相应的目录，并运行：

   patch < issuepatch.diff

3. 请始终在您的修补程序中包含具有以下信息的消息：

   • 对您要尝试修复的问题或缺陷的描述以及再现该问题或缺陷的步骤（如果可能）。
   • 对安装好修补程序后的行为的描述。
   • 对修补程序如何工作的描述（如果合适）。如果涉及大量代码，则在消息中说明您同意其他人在适用的项目许可下将修补程序用作 IDE 的代码的一部分。
   • 测试用例包括 Jave 源代码、脚本和文档，所以我们可以将此测试包含在 appserv-test/devtests 测试套件中。
     

负责受影响的代码部分的开发者应该应用修补程序并将缺陷（如果有注册的缺陷）标记为已修复，或者将其拒绝（如果修补程序看起来并不安全，或修补程序看起来不能修复问题，或并没有一个真正需要解决的问题）。任何对问题数据库的更改的通知以及 CVS 签入都会自动发送到相应的问题负责人并抄送 CVS 邮件列表，这样您就可以监视修补程序是否被应用。确保至少订阅了您正在从事的项目的 CVS 和问题邮件列表。

如果您并不十分清楚如何修复问题，但有关于问题是如何产生的想法，那么您可以在开发者讨论列表上发送相关邮件以获取其他项目成员的建议或是找到某个知道如何修复它的成员。