《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。
《Drools6.4 中文文档》第1章1.1~1.2(完)_第1张图片

1.2.7 提交Pull请求

当你的代码已经从原始主干rebase,并且push到你的GitHub,你可以提交你的代码作为一个pull请求了。在你工作区域的GitHub页面顶部有一个“Pull Request”按钮。选中,就会提供一个自动提交pull请求的图形界面。
这个pull请求会进入一个队列,所有人都可以看到并且进行注释。下面,你将看到一个典型的pull请求。Pull请求允许讨论,展现所有相关提交和每次提交的差异。讨论一般涉及代码review,提供有用的建议和改进,允许我们离开内联注释代码的特定部分。如果我们没有一次通过,请不要气馁,一般需要多次修正才能真正被接受。幸运的是GitHub可以轻松的返回到你的代码,做一些提交,然后更新你的pull到最新、最好。
我们需要花一些时间来相应这些pull请求,请耐心等待。提交测试,修复通常会很快被应用,只是测试经常要等到我们抽出时间进行修复提交。
《Drools6.4 中文文档》第1章1.1~1.2(完)_第2张图片

备注

最近开始研究drools,发现6.4版本没有中文文档,就尝试着翻译学习。如有问题,请及时指出,谢谢!

你可能感兴趣的:(Drools,Drools规则引擎)