git clone http://github.com/grails/grails-core.git21 对 Grails 贡献
版本 6.2.0
21 对 Grails 贡献
Grails 是一个开放源代码项目，拥有一个活跃的社区，我们严重依赖该社区来帮助改进 Grails。因此，人们可以通过多种方式对 Grails 做出贡献。其中一种方式是编写有用的插件并公开它们。在本章中，我们将介绍一些其他选项。
21.1 在 Github 问题追踪器中报告问题
Grails 使用 Github 在核心框架中追踪问题。类似地，对于其文档来说，也有一个独立追踪器。如果你发现了一个错误，或希望看到一个特定功能添加进来，这些就是着手的地方。你需要创建一个（免费的）github 帐户，以便在任何一种情况下提交问题或评论现有问题。
在提交问题时，请提供尽可能多的信息，并且如果发生了错误，请确保说明你使用了哪些版本的 Groovy、Grails 和各种插件。还应包括其他环境详细信息 - 操作系统版本、JDK、Gradle 等。此外，如果你上传一个可复现的示例应用程序至 github 存储库并在问题中提供链接，那么问题被处理的可能性就更大。
审阅问题
github 中有不少旧的问题，其中一些可能不再有效。核心团队无法单独追踪这些问题，因此您可以偶尔验证一两个问题，这是一个非常简单的贡献。
哪些问题需要验证？转到 问题跟踪器将显示尚未解决的所有问题。
验证问题后，只需添加简短注释说明您发现的内容。务必注明您的环境详细信息和 grails 版本。
21.2 从源代码构建并运行测试
如果您有兴趣向 grails 的任何部分添加修复和功能，您将需要学习如何获取项目的源代码、构建它以及使用您自己的应用程序对其进行测试。在开始之前，请确保您拥有
-
JDK（11 或更高版本）
-
git 客户端
安装所有必需的包后，下一步是从 GitHub 下载 Grails 源代码，该源代码由 "grails" GitHub 用户 拥有的多个存储库托管。这是一个简单的情况，即克隆您感兴趣的存储库。例如，要获取核心框架运行
这将在您的当前工作目录中创建一个 "grails-core" 目录，其中包含所有项目源文件。下一步是通过源代码获取 Grails 安装。
创建 Grails 安装
如果您查看项目结构，您会发现它看起来不像标准的 GRAILS_HOME 安装。但将其变成一个非常简单。只需从项目的根目录运行以下内容
./gradlew install这将获取 Grails 所需的所有标准依赖关系，然后构建 GRAILS_HOME 安装。请注意，此目标跳过了大量 Grails 测试类，这些测试类可能需要一些时间才能完成。
完成上述命令后，只需将 GRAILS_HOME 环境变量设置到签出目录，并将 "bin" 目录添加到您的路径中。在您下次键入 grails 命令运行时，您将使用刚构建的版本。
如果您正在使用 SDKMAN，那么它还可以通过以下方式用于处理此本地安装
sdk install grails dev /path/to/grails-core您还需要将本地安装发布到本地 maven。
./gradlew pTML
现在您将在本地拥有一个开发版本，可用于测试您的功能。
运行测试套件
运行全套测试所需要做的就是
./gradlew test这将花费一些时间（15-30 分钟），因此请考虑使用命令行运行单个测试。例如，要运行测试规范 BinaryPluginSpec，只需执行以下命令
./gradlew :grails-core:test --tests *.BinaryPluginSpec请注意，您需要指定测试用例所在的子项目，因为顶级 "test" 目标不起作用……
在 IntelliJ IDEA 中开发
您需要运行以下 gradle 任务
./gradlew idea然后打开 IDEA 中生成的项目文件。简单！
在 STS / Eclipse 中进行开发
您需要运行以下 gradle 任务
./gradlew cleanEclipse eclipse在将项目导入 STS 之前执行以下操作
-
编辑 grails-scripts/.classpath 并删除 "<classpathentry kind="src" path="../scripts"/>" 行。
使用“导入→常规→现有项目进入工作空间”将所有项目导入 STS。会出现一些构建错误。要修复它们，请执行以下操作
-
将 $GRAILS_HOME/lib/org.springsource.springloaded/springloaded-core/jars 中的 springloaded-core JAR 文件添加到 grails-core 的类路径。
-
从 grails-plugin-testing 的源路径中删除“src/test/groovy” GRECLIPSE-1067
-
将 $GRAILS_HOME/lib/javax.servlet.jsp/jsp-api/jars 中的 jsp-api JAR 文件添加到 grails-web 的类路径。
-
修复 grails-scripts 的源路径。添加链接到“../scripts”的链接源文件夹。如果您在 grails-scripts 中遇到构建错误，请在该目录中执行“../gradlew cleanEclipse eclipse”并再次编辑 .classpath 文件（删除 "<classpathentry kind="src" path="../scripts"/>" 行）。如果无法添加链接文件夹，请删除 grails-scripts 下可能存在的空“scripts”目录。
-
对整个工作空间进行清理构建。
-
要使用 Eclipse GIT scm 团队提供程序：在导航中选择所有项目（“服务器”除外），然后右键单击 → 团队 → 共享项目（不是“共享项目”）。选择“Git”。然后选中“在项目的父文件夹中使用或创建仓库”，然后单击“完成”。
-
从 邮件列表主题（尚未决定最终风格，目前为 profile.xml）获取推荐的代码样式设置。将代码样式 XML 文件导入 STS，方法是单击窗口→首选项→Java→代码样式→格式程序→导入。Grails 代码使用空格而不是制表符进行缩进。
调试 Grails 或 Grails 应用程序
要启用调试，请运行
./gradlew bootRun --debug-jvm默认情况下，Grails 会分叉一个 JVM 来运行应用程序。-debug-jvm 参数会导致调试器与分叉的 JVM 相关联。
21.3 提交补丁到 Grails Core
如果您想将补丁提交到项目，只需在 GitHub 上分叉仓库而不是直接克隆它。然后，您将提交更改到您的分叉并发送一个拉取请求供核心团队成员审阅。
分叉和拉取请求
以下是帮助确保快速处理您的拉取请求并提供我们所需信息的准则。它们也会让您轻松自如地协作！
确保您的分叉是最新的
对过时的源进行更改不是一个好主意。别人可能已经做了更改。
git pull upstream master为您的更改创建一个本地分支
如果您创建一个本地分支，就可以更轻松地对您的更改进行操作。例如，只要您分叉一个仓库并在本地克隆分叉，就可以执行
git checkout -b issue_123这会基于“主”分支创建一个名为“issue_123”的新本地分支。当然，你可以根据喜好来命名分支，但好主意是引用与更改相关的 GitHub 问题编号。每个 Pull Request 都应有其自己的分支。
为非平凡的更改创建 GitHub 问题
对于任何非平凡的更改，如果尚未存在，则在 github 上引发一个问题。这有助于我们追踪哪些更改进入到 Grails 的每个新版本中。
在提交消息中包含 github 问题 ID
这一点可能看起来不是特别重要，但在提交消息中包含 github 问题 ID 意味着我们可以在之后得出更改被执行的原因。在所有与该问题相关的提交中包含该 ID。如果某个提交与某个问题无关，那么无需包含问题 ID。
确保你的 fork 是最新版本并重新设置基准
由于核心开发者必须将你的提交合并到主仓库中，在发送 pull request 之前，如果你的 GitHub 上的 fork 是最新版本会让过程轻松很多。
假设你已将主仓库设置为名为“upstream”的远程并希望提交一个 pull request。此外，你所有的更改当前在本地“issue_123”分支上，但不在“主”分支上。第一步涉及从主仓库中拉取上次获取并合并后添加的任何更改
git checkout master
git pull upstream master这应能毫无问题或冲突地完成。然后，针对现在已更新的主重新设置你本地分支的基准
git checkout issue_123
git rebase master该操作将重新排列提交，以便所有更改都位于主中的最新一个之后。可以将其想象为将一些卡片添加到一副牌的顶部，而不是将其洗入到整副牌中。
将你的分支推送到 GitHub 并且发送 Pull Request
最后，你必须将更改推送到你的 GitHub 上的 fork 中，否则核心开发者将无法获取它们
git push origin issue_123| 你不应该将你的分支合并到 forks 主中。如果 Pull Request 未被接受，那么你的主将永远与上游不同步。 |
你现在已准备好从 GitHub 用户界面发送 pull request。
说明你的 pull request 的作用
一个 pull request 可以包含任意数量的提交，并且可以与任意数量的问题相关。在 pull request 消息中，请指定请求所涉及的所有问题的 ID。此外，请提供你已完成工作的简要说明，例如：“我重构了数据绑定器，并添加了对自定义数字编辑器的支持。修复了 #xxxx”。
21.4 向 Grails 文档提交补丁
贡献简单更改
用户指南使用 Asciidoctor 编写。贡献修复的最简单的方法是，只需单击文档的每个部分右侧的“改进此文档”链接。
这会链接到 GitHub 编辑屏幕，在其中你可以进行更改，预览它们并创建一个 pull request。
构建指南
如果您想要进行重大更改，比如更改目录结构等等，我们建议您创建用户指南。要实现此目的，只需从 github 中签出源文件即可
$ git clone https://github.com/grails/grails-doc/
$ cd grails-doc源文件位于 src/en/guide 目录中。而目录 (TOC) 则在 src/en/guide/toc.yml 文件中定义。
每个 YAML 键项都指向一个 Asciidoc 模板。例如，请考虑以下 YAML 代码
introduction:
title: Introduction
whatsNew:
title: What's new in Grails 3.2?
...introduction 键项指向 src/en/guide/introduction.adoc。title 键项定义目录中显示的标题。由于 whatsNew 键项嵌套在 introduction 键项之下，因此它指向 src/en/guide/introduction/whatsNew.adoc，该文件嵌套在一个名为 introduction 的目录中。
基本上，利用 toc.yml 文件和目录结构，您可以处理用户指南的结构。
要生成文档，请运行 publishGuide 任务
$ ./gradlew publishGuide -x apiDocs在上述示例中，我们跳过了 apiDocs 任务以加快指南的构建速度，否则将同时构建所有 Groovydoc 文档！ |
构建指南后，只需在浏览器中打开 build/docs/index.html 文件即可查看您的更改。