开发者区域

GPars 开发人员信息

构建信息

持续集成构建可以在以下位置找到

表 1. 构建服务器
构建服务器 链接 备注

---

---

---

Travis-CI

GPars

Travis-CI 状态 master

Snap-CI

GPars/branch/master

Snap-CI 状态 master

JetBrains TeamCity

jetbrains.com

需要注册

问题跟踪器

JIRA 问题跟踪器: http://jira.codehaus.org/browse/GPARS - 不再有效。

源代码仓库

GitHub 上托管的 Git 仓库是官方主线: 我们的仓库在这里。

要参与代码库开发，请按照常规的 GitHub 工作流程在 GitHub 上 Fork 仓库。将 master 分支作为主线镜像，在特性分支上进行开发，然后基于该特性分支提交 Pull Request，这似乎是最佳的工作方式。有关使用 Git 和 GitHub 的更多细节，请参考 Git 和 GitHub 文档。

镜像仓库

为了继续与各种持续集成服务器集成，在 Codehaus（在他们关闭之前）维护了一个 GitHub 仓库镜像。Codehaus 项目也是我们问题跟踪器的所在地，也是构件进入 Maven 仓库的途径。

您永远不需要克隆此仓库，但为了完整起见，命令

git clone https://github.com/GPars/GPars.git

在 GPars 子目录中创建一个仓库克隆。此 URL 提供对仓库的只读访问。

个人克隆

项目提交者和贡献者通常会保留主仓库的个人克隆，用于特性分支。

  • Vaclav Pech

  • Russel Winder

构建项目

包含了 Gradle 构建工具包装器，因此运行 gradlew 构建脚本将为项目下载和设置 gradle，并执行构建。

IDE 集成

通过 gradlew idea 或 gradlew eclipse 命令创建 IDEA 或 Eclipse 项目文件，您就可以开始了。

IntelliJ IDEA

在启动或构建项目之前，IDEA 会提示您使用哪个 JDK 版本。在项目级别指定后，您就可以开始构建了。

默认 IntelliJ IDEA 项目文件

GPars 在项目的根目录中包含一个默认的 IDEA 项目文件，名为 GPars_IDEAX.ipr。此项目充当生成的项目文件（见上文）的主副本，也用于配置我们的持续集成。如果您由于某种原因决定使用默认项目文件，则需要先执行一些配置步骤。

第一次打开项目时，系统会提示您输入 PROJECT_JDK_NAME 和 MAVEN_REPOSITORY 变量。这些是 IDEA 变量，而不是系统变量。这些结果存储在您的主目录中。

每个开发人员都可以拥有唯一的变量值。例如，您的 MAVEN_REPOSITORY 可能是磁盘上的某个路径，PROJECT_JDK_NAME 可以是任何字符串值，例如 "1.6"。这是在 IDEA 中定义的全局 JDK 的名称。

您可以在 IDEA 的 文件→项目结构→SDK 下设置全局 JDK。有一个小的文本框供您输入 JDK 的名称。您在文本框中输入的内容就是需要在 IDEA 环境变量屏幕中为 PROJECT_JDK_NAME 输入的内容。

MAVEN_REPOSITORY 变量应该指向您的本地 maven 仓库，IDEA 将使用它来保存构建和运行 GPars 所需的第三方库的可下载构件。您需要先填充仓库，以便 IDEA 找到必要的构件。最好的方法是打开 /java-demo/pom.xml 文件（前提是在您的 IDEA 安装中启用了 Maven 支持），然后让 IDEA 导入更改。

或者，您也可以使用 Maven 工具窗口中的 刷新按钮。

未来的 IDEA 环境变量可以在 .ipr 和 .iml 中使用语法 $VAR_NAME$ 进行声明。在项目启动时未定义的任何变量都会提示用户输入。

代码风格

如果您打算为项目贡献代码，请查看我们的简短 代码风格指南，以确保您的贡献与代码库的其余部分无缝衔接。

VCS 工作流程

  1. 人们克隆了 GitHub 主仓库

  2. 人们在他们的个人克隆仓库中创建了特性分支

  3. 人们发布他们的工作，以便可能与其他人合作开发特性，并在准备好进行审查时宣布分支，并要求其他人进行审查。（git push [mirrorRepo] myFeature）

  4. 审查特性分支的人员将从公共镜像中获取变更集，并审查运行测试（[git remote add mirrorRepo mirrorRepoUrl;] git fetch [mirrorRepo] myFeature）

  5. 如果没有对提议的更改有任何担忧，那么人们会表示同意，或者如果存在问题，则在邮件列表中开始讨论。

  6. 当更改已过审查并达成一致后，提交者之一会同意将分支合并到他们的 master 分支，并将更改推送到 GitHub 主仓库（当然还有他们的公共镜像仓库）（git checkout master; git pull; git merge --no-ff myFeature;git push）

请注意合并时使用了 --no-ff 标志。

请注意，此工作流程适用于所有人，无论他们是提交者还是非提交者。只是非提交者必须说服提交者进行提交。结果是，不应建议人们在 JIRA 问题中提交补丁，而应指定他们的特性分支所在的位置，以便可以将其拉取。显然，补丁也行得通，但重点是每个人都发布他们的特性分支，以便其他人可以在 VCS 上下文中审查它们。

简化工作流程

微不足道的拼写错误修复、不需要更改代码但只是扩展测试范围的额外测试以及非常简单（无争议）的错误修复（及其测试）目前无需审查流程。

此处需要提交开发人员的谨慎判断。（git pull; fix; commit; git push）或（git pull; git checkout -b myFix; fix; commit; git checkout master; git pull; git merge --no-ff myFix;git push）

升级 Gradle

  1. 从最新的 Gradle Trunk 或新的 SDK 安装程序工具安装 Gradle

  2. 编辑 build.gradle 或 gradle.properties 文件，将包装器的编号更改为新的编号。

  3. 运行 gradle wrapper

  4. 如果包装器是快照，则编辑 wrapper/gradle-wrapper.properties，将仓库 URL 中缺少的快照添加回来

  5. 使用 git diff 检查结果

  6. 使用 gradlew clean test 检查结果

  7. 如果在 Linux 上，请检查 Bamboo 构建是否可以通过 env -i ./bambooBuild 进行工作

  8. 如果一切顺利，则提交结果 git commit -m ' . . .' -a

  9. 推送到主线 git push

  10. 推送到个人镜像 `git push --mirror . . . `

  11. 满怀期待地等待，看看 Bamboo 是否正常工作 . . .

发布计划

1. 设置版本

在 build.gradle 和 doc.properties 中设置版本属性

还要更新 ReleaseNotes.txt 文件。

2. 编写更新内容

更新用户指南中的“更新内容”部分以及 ReleaseNotes.txt 文件。

3. 标记源代码

在进行正式发布后，在 VCS 中创建一个标签，其中包含用于进行发布的源代码。使用 release-x.x 模式标记标签。

4. 构建项目

对快照或正式发布进行完整重建

确保所有演示程序都能正常运行

5. 上传构件

在 Bamboo 上运行发布构建计划，这将使所有构件可供下载。

6. 更新 Maven 仓库

确保您的仓库凭据位于 $USER_HOME/.gradle/gradle.properties 中，或者在 build.gradle 中的 uploadArchives 任务中直接指定您的凭据，并将 uploadArchive 任务添加到所需的构建任务中

确认构件已成功上传以进行正式发布。在几个小时内，新的正式发布应该会传播到位于 http://repo1.maven.org/maven2/org/codehaus/gpars/gpars/ 的 maven 中央仓库中。

7. 清理快照仓库

在进行正式发布后，应从快照仓库中手动删除旧的快照构件。任何 webdav 客户端，例如 AnyClient http://www.anyclient.com/download.html 都应该能够做到这一点。

8. 上传用户指南和文档

生成的 用户指南 位于 /build/docs/manual，应上传到 GPars 文档网站 。

javadoc 和 groovydoc 文件夹也应该被复制。

9. 更新版本

在进行正式发布后，必须将构建文件中的版本更改为下一个版本。

10. 更新 JIRA

正式发布也应该在 JIRA 中关闭。

11. 通知大家

人们迫切地等待着新的 GPars 功能，现在是告诉他们的时候了。新的正式发布应该在以下邮件列表和网站上宣布