Drools Kie application without Maven

Question

As a developer I want to create a Maven project and build an executable standalone JAR application. (No Spring Boot)

During development and build processes I want to add a Drools Kie artifact as dependency

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

build my application as executable Jar and run it. My application has the code to call the Drools engine:

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

Above all, whilst I deploy my application on production:

• I do not want to install Maven on my production server
• I do not want my application to scan a local nor remote Maven repository
• I want my application automatically scans periodically for a new version of my Drools Kie artifact without any reference to a Maven repository, just looking at the filesystem

I have tried with

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 );

Loading the JAR works fine, but it seems that I am also forced to configure at least a minimal Maven repository (~/.m2 folder and a settings.xml). I get a heap of errors by the org.apache.maven plugin and related classes.

Of course I do not want my production environment to rely nor depend on any Maven configuration. I just want to run a JAR with another JAR (e.g. libs/mydrools-1.0.0.jar) as dependency and possibly dynamically reload that dependency whilst I update the libs/mydrools-1.0.0.jar.

Basically I need to set the internal Drools Kie Maven plugin completely disabled (offline).

How is it possible to do this with Drools 6.2.0.Final?

Update

This issue is strictly related with

Using Drools 6 Maven architecture completely offline

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

Morganmorgana

I suppose that scanning the file system is best done by java.nio.WatchService, to see whether a new KieBase has been deployed. Building (i.e., Drools compiling) should be done in the development environment. (I don't see a good reason to "run the Drools engine" during "development and build processes".) – Crescentia

The good reason is that using KieScanner - so reloading dynamically the artifact - is the way to update the engine with no service disruption (no stop, re-deploy and restart). But nobody would let a production application browsing a (even internal) Maven repository: I do not want Drools Kie to reload artifacts I might not have under my control (e.g. org.apache.*). I want Kie reloads only my custom Drools artifact, nothing else, and without Maven. Just a Jar file. – Morganmorgana

Note that "running the Drools Engine" means that you run a session created from a Knowledge Base, applying rules to objects inserted as facts. So: why "run the Engine" during "development and build"? – Crescentia

OK, my description is inaccurate, those are two separate steps: - dev & build & deploy: my Drools artifact is a Maven dependency to build (and later on) deploy somewhere my executable Jar - my executable Jar will run the Drools engine – Morganmorgana

Then we are back to my original statement: use WatchService to see whether a new KieBase has been deployed. - I'm not sure about the "no service disruption", though. A new KieBase is a full new set of rules, replacing, adding, deleting rules. How should this work with state in all forms being in facts, agenda and the Engine? – Crescentia

Yes, this is another story, of course. From now we want to start with a stateless ruleset, so the engine won't "remember" anything about previous facts and rules. – Morganmorgana

Answer 1

The answer is you don't. KIE 6.* (and 7) has maven built into it, the KieScanner class uses maven to find updates. The scanner will work better if in the ReleaseId you specify a version range e.g. [1.0.0,)

My company is in the process of deploying KIE based applications to production. We're setting up an Artifactory repository in PROD and there will be a maven repository as well.

You can essentially disable the maven part by not using KieScanner, instead use the getKieClasspathContainer() to get the KIE container. You won't be doing dynamic updates to rules though.

KIE also provides an Execution Server which pushes the Rules into a REST API. The Execution Server rules can also be updated via maven.

Furry

Your answer confirms our concerns and the reason why we want to move from a Maven / external jar solution to a completely RESTful application (which incidentally is provided within the latest versions of Drools) – Morganmorgana

Does KIE 7.* also come with Maven built into it? – Ablative

Answer 2

Architecturally speaking, you have three rule deployment models:

Model #1 is a dynamic rule updating mode. In 5.3 it pulled compiled classes over http, now in 6 & 7 it uses maven as the transport since it provides versioning and is by far the most prolific artifact versioning and transport tool. In this mode you have a production application (jar or war) which pulls rules (over maven aether through kie-ci) from a maven repo (you can have a dedicated maven repo for PROD if you like). If you use this model then you need kie-ci as a dependency and it will magically use maven under the hood.

You could use the scanner & have a maven settings.xml configured that has no <servers>, and therefor it should only pull from the production server ~/.m2 folder, allowing you to deploy to the server file system and use the OOTB scanner without any danger of it pulling externally.

Model #2 is a immutable rule model. So the concept is that you embed the rules in the application as a resource, they cannot be updated. This works well with immutable deployments such as CD pipelines and container/docker deployments that need to test the state of the app as it is right now. Having said that containers don't prohibit the option to dynamically update, I'm speaking from a pure architectural perspective. For this more omit kie-ci from the deps and use the 'getKieClasspathContainer()' (as whomer said) to load the rules from the resources folder and it will never attempt to update without redeploying the app.

Model #3 is a centralized "server" mode (and I'm only adding it for completeness due to it's limited use). It's where you centrally execute rules outside of your application's runtime, made popular by IBM's rule (and marketing) engine. However it is inferior for most use cases except in a managed service type application where you want to cross-charge. It doesn't scale naturally along with the app, entities have to be de/serialized over the wire so performance is poor etc.. however you do get central logging.

Trichinosis

In the Model#2, "omit kie-ci from the deps" was a life saver for me. – Chicken