How to migrate from drools 5 to drools 7?

Question

Does anyone know of a tool or some form of documentation for migrating from drools 5 to drools 7? There doesn't seem to be a clear path forward on this.

Answer 1

You don't.

I upgraded an application from Drools 5.0.1 to Drools 7.22 (the latest at the time). By the time I finished, it was effectively a rewrite. Even 5.x to 6.x is a non-trivial upgrade.

The basic steps I followed were:

1. Update the rules themselves to follow the modern syntax. Drools 5 was a lot more permissive, and some of the things it allowed back then are no longer permitted now. For example, single-line comments can no longer start with #. Other things I focused on were making sure things were typed appropriately when I extracted them from objects (Drools 5 was surprisingly permissive there; I had rules that declared all sorts of types that were flat out wrong and Drools 5 just ... dealt with it.)

   When I did this myself, I updated each of our DRLs to follow the new syntax, then checked them individually in a simple Drools 7 harness that I built that would just load up the rules (to make sure they compile), and throw data at them. I also used the IntelliJ IDEA IDE which has Drools syntax/code hilighting support and is pretty good at identifying syntax errors most of the time; so basically the goal was for each modified file to not have any red squiggly underlines indicating a problem.

2. Write unit tests. I covered all of the existing rules with unit or behavioral tests (Cucumber) so that I could be certain that, post upgrade, everything still functioned as it did prior to the upgrade. This also bought me time with management since they like "code coverage" as a metric.

3. Replace the libraries and deployment logic. This is going to be extremely dependent on how you've set it up in your application, but at least in mine we had abstracted all of our rules management code into a single dependency, so I could in theory just update it all in one place.

   In Drools 5, your folder organization of your rules was pretty much arbitrary; now it needs to match your package structure. (eg. if you have something in rules/foo/bar, you need to declare your package as rules.foo.bar in the DRL.) The kmodule xml also needs to be updated to describe the location of all of your rules. I recommend using the kmodule xml because it makes loading the rules stupidly easy -- none of this manually setting up file systems and what not.

4. Run your unit tests. If any of them fail, go back to the rule it's exercising and figure out what's wrong with it.

5. Claim victory. And 100% test coverage on your rules. ;)

It only took me about 9 months to do this all, but I also had 40,000 or so rules I needed to (effectively) rewrite. (And I had regular work to do as well; this wasn't a full time, heads-down effort.)

(Before you even begin, it's useful to stand up a toy application using Drools 7 so you can understand the new classes and syntax and how the rules are loaded. A lot of it is pretty similar, eg KieBase instead of RuleBase, but some of it is rather different.)