没有Maven的Drools Kie应用程序

Question

作为开发人员，我想创建一个Maven项目并构建一个可执行的独立JAR应用程序。 （没有春靴）

在开发和构建过程中，我想添加一个Drools Kie工件作为依赖项

<dependency>
 <groupId>com.mycompany</groupId>
 <artifactId>mydrools</artifactId>
 <version>[1.0.0,)</version>
</dependency>

将我的应用程序构建为可执行Jar并运行它。 我的应用程序有代码来调用Drools引擎：

KieSession kSession = kContainer.newKieSession();
kSession.insert(myBean);
kSession.fireAllRules();

最重要的是，当我在生产中部署我的应用程序时：

• 我不希望我的生产服务器上安装Maven
• 我不希望我的应用程序扫描本地或远程Maven存储库
• 我希望我的应用程序能够定期自动扫描我的Drools Kie工件的新版本， 而无需参考Maven存储库，只需查看文件系统

我试过了

String fileName = System.getenv("HOME") + "/libs/mydrools-1.0.0.jar";
File file = new File(fileName);
KieRepository kieRepository = ks.getRepository();        
KieContainer kContainer = ks.newKieContainer(ks.newReleaseId("com.mycompany", "mydrools", "1.0.0"));
kieRepository.addKieModule(ks.getResources().newFileSystemResource(file));
KieScanner kScanner = ks.newKieScanner( kContainer );
kScanner.start( 10000L );

加载JAR工作正常，但似乎我也被迫配置至少一个最小的Maven存储库（〜/ .m2文件夹和一个settings.xml）。 我通过org.apache.maven插件和相关类获得了一堆错误。

当然，我不希望我的生产环境依赖于任何Maven配置。 我只想用另一个JAR（例如libs / mydrools-1.0.0.jar）作为依赖项运行JAR，并且可能在更新libs / mydrools-1.0.0.jar时动态重新加载该依赖项。

基本上我需要设置内部Drools Kie Maven插件完全禁用（离线）。

如何用Drools 6.2.0.Final做到这一点？

更新

这个问题严格关系到

使用Drools 6 Maven架构完全脱机

http://lists.jboss.org/pipermail/rules-users/2014-June/036245.html

Answer 1

答案是你没有。 KIE 6. *（和7）内置了maven，KieScanner类使用maven来查找更新。 如果在ReleaseId中指定版本范围，例如[1.0.0，）扫描程序将更好地工作

我的公司正在将基于KIE的应用程序部署到生产环境中。 我们在PROD中设置了Artifactory存储库，并且还将有一个maven存储库。

您实际上可以通过不使用KieScanner来禁用maven部分，而是使用getKieClasspathContainer（）来获取KIE容器。 但是，您不会对规则进行动态更新。

KIE还提供了一个Execution Server，它将Rules推送到REST API中。 Execution Server规则也可以通过maven更新。

Answer 2

从架构上讲，您有三种规则部署模型：

模型＃1是动态规则更新模式。 在5.3中它通过http提取编译类，现在在6和7中它使用maven作为传输，因为它提供版本控制，并且是迄今为止最多产的工件版本控制和传输工具。 在这种模式下，你有一个生产应用程序（jar或war）从maven repo中提取规则（通过kie-ci的maven aether）（如果你愿意，你可以为PROD设置一个专用的maven repo）。 如果你使用这个模型，那么你需要kie-ci作为依赖，它会神奇地使用maven在引擎盖下。

您可以使用扫描程序并配置一个没有<servers>的maven settings.xml ，因此它只应从生产服务器~/.m2文件夹中提取，允许您部署到服务器文件系统并使用OOTB扫描程序没有任何外部拉动的危险。

模型＃2是不可变的规则模型。 因此，概念是您将规则作为资源嵌入应用程序中，它们无法更新。 这适用于不可变的部署，例如CD管道和容器/ docker部署，需要像现在一样测试应用程序的状态。 虽然说容器没有禁止动态更新的选项，但我从纯粹的架构角度讲。 为了更多地省略来自deps的kie-ci并使用'getKieClasspathContainer（）'（如whomer所说）从resources文件夹加载规则，它将永远不会尝试更新而不重新部署应用程序。

模型＃3是一种集中的“服务器”模式 （由于它的使用有限，我只是为了完整性而添加它）。 它是您在应用程序运行时之外集中执行规则的地方，受到IBM规则（和营销）引擎的欢迎。 但是，对于大多数用例而言，它除了在您想要交叉充电的托管服务类型应用程序之外都不如此。 它不会随应用程序自然扩展，实体必须通过线路进行解序/序列化，因此性能很差等等。但是你确实得到了中央记录。