《Drools6.4 中文文档》第1章1.1~1.2（完）
# 第一章 介绍
1.1 介绍
自从5.x系列版本发布开始，整个引擎有了很多的变化。
在使用5.x系列中最大的抱怨之一就是缺少部署的方法定义。Drools 和jBPM使用的机制非常灵活，但是它太灵活了。而6.0最值得关注的就是它简化了构建、部署和系统装载。现在，构建和部署时采用与Maven相结合，装载时用面向约定和配置代替了原来的面向编程的方式，适当的默认了一些参数项，使配置达到了最小化。
Workbench进行了彻底的重构，灵感来自于eclipse，提供了一个灵活的更好的整合方案。通过插件来展现控制和构建面板。基础的Workbench已经拆分成单独的项目，命名为UberFire。所以，现在任何人都可以基于Workbench构建出高质量的web项目。从长远来看，它会促使用户个性化的定制Drools和jBPM安装。
Git取代了JCR来管理版本库，它提供了一个快速、可扩展、拥有强大工具支持的后端内容存储管理。另外一个聚焦点是数据库的简化，所有的数据都以文本文件的形式来存储，甚至动态变化的数据也只是一个文件。数据库只提供快速的索引和通过Lucene搜索的功能。版本库将通过已有的工具来进行同步和发布，比如使用GitHub。
jBPM在人工任务、表单构造器、类模型、执行服务、运行时管理等方面已经被显著的加强了，这得益于Polymita的收购。
OptaPlanner是当前的一个顶级项目，所有的时间和精力都集中在这上面了。
一个新的统称，KIE(Knowledge Is Everything)，已经被引进并与相关的技术融合。它也作为我们项目的共享核心。对它多一些期待吧。
1.2 参与
我们经常被问到：我怎样才能参与其中呢。答案很简单，只用写一些代码并提交它。没有特定的制约或秘密协议。唯一的要求就是可扩展的项目开发。下面，我们提供一些工具和工作流的常规介绍，同时提供一些常规的建议。
如果你贡献了一些很棒的工作，别忘记用博客把它写下来。
1.2.1 注册jboss.org账号
注册jboss账号，可以访问JBoss Wiki、论坛和JIRA。访问http://www.jboss.org/，点击注册。
PS：此地址页面已经有所改版，原文档截图不完全匹配，个人可自行点击网址，点击注册。
1.2.2 签署贡献者协议
唯一需要填写的一个表单是贡献者协议，全程操作都是通过web页面。像下面的截图上所说“这为您的贡献建立了条款和条件，并确保源代码可以适当地授权”。https://cla.jboss.org/
PS：自行点击页面进行签署。
1.2.3 通过JIRA提交问题
为了能够与核心研发团队进行交流，你需要使用JIRA，问题追踪系统。确保所有请求都被记录、分配发布时间表，所有讨论都集中在这里。Bug报告，Bug修复，新增功能和功能提交都需要集中到这里。一般问题通过邮件接收。
次要代码提交，比如格式化或文档修改不需要创建一个关联的JIRA问题。 https://issues.jboss.org/browse/JBRULES (Drools) https://issues.jboss.org/browse/JBPM https://issues.jboss.org/browse/GUVNOR
PS：自行点击前往页面。
1.2.4. Fork GitHub
签署完贡献者协议，在JIRA上提交完请求，现在该准备好编写代码了。创建一个GitHub账号，fork Drools、jBPM 或 Guvno的任一版本库。Fork命令会复制一份到你的GitHub，你可以在这里进行编写代码。如果出现错误，删除重新Fork一份即可。注意每一个GitHub库为您提供克隆的URL，GitHub将针对你的Fork项目提供对应的URL地址。 https://github.com/droolsjbpm
PS：自行点击前往页面。
1.2.5 编写测试
在编写测试代码时，尽量保持代码的简短和自包含性。我们更希望能将DRL代码块包含在测试中，以方便更快的进行审核。如果是大量的规则，那么使用一个字符串是不切合实际的。通过各种方法将它们分割到不同的DRL文件，而不是直接从classpath进行加载。如果测试用到model，请尝试使用那些已经存在的被其他测试使用的model。比如，Person，Cheese或Order。如果没有包含你需要的字段的类存在，在添加一个新类之前，优先考虑在已有类上添加字段。 有大量的测试代码可以借鉴，MiscTest类是一个很好的开始。 https://github.com/droolsjbpm/drools/blob/master/drools-compiler/src/test/java/org/drools/integrationtests/MiscTest.java
PS：此地址已经无法找到此类，可以参考其他类。
1.2.6 提交约定
当进行代码提交时，请遵循正确的约定。提交必须以问题ID作为开始，比如JBRULES-220。确保提交版本和JIRA相互对照，这样我们可以在一个问题下看到所有的提交版本。在ID下面，应该是问题的标题。换行、缩进，提供本次提交的附加信息。当你要建立分割点时，使用换行和缩进。如果合适，你可以添加额外的JIRA信息与提交建立关联。一般，尽量避免组合无关的问题到同一提交中。 别忘了从原主干rebase你本地分支，然后push你的提交到你的fork。
1.2.7 提交Pull请求
当你的代码已经从原始主干rebase，并且push到你的GitHub，你可以提交你的代码作为一个pull请求了。在你工作区域的GitHub页面顶部有一个“Pull Request”按钮。选中，就会提供一个自动提交pull请求的图形界面。 这个pull请求会进入一个队列，所有人都可以看到并且进行注释。下面，你将看到一个典型的pull请求。Pull请求允许讨论，展现所有相关提交和每次提交的差异。讨论一般涉及代码review，提供有用的建议和改进，允许我们离开内联注释代码的特定部分。如果我们没有一次通过，请不要气馁，一般需要多次修正才能真正被接受。幸运的是GitHub可以轻松的返回到你的代码，做一些提交，然后更新你的pull到最新、最好。 我们需要花一些时间来相应这些pull请求，请耐心等待。提交测试,修复通常会很快被应用，只是测试经常要等到我们抽出时间进行修复提交。
备注
最近开始研究drools，发现6.4版本没有中文文档，就尝试着翻译学习。如有问题，请及时指出，谢谢！