# Apache KIE: Drools, OptaPlanner, jBPM and Kogito in One Incubating Repository > Apache KIE bundles four Java engines for rules, constraint solving, workflows and cloud-native automation. This is what each component does, how the Maven coordinates are organized, and where the repository is thin. **apache/incubator-kie** — Apache KIE (Knowledge Is Everything) is the home of Drools, OptaPlanner, jBPM, and Kogito. - Repository: https://github.com/apache/incubator-kie - Website: https://kie.apache.org - Stars: 6,330 · Forks: 2,602 - Language: Java - License: Apache-2.0 - Published: 2026-09-22 · Updated: 2026-09-22 · Language: en - Canonical page: https://hysenlabs.com/projects/apache-incubator-kie ## Four Java engines under one Apache incubator umbrella Apache KIE is not a single product. The README describes it as the home of Drools, OptaPlanner, jBPM and Kogito, and the repository root confirms that by carrying a top-level directory for each: drools-core, drools-compiler, drools-decisiontables and dozens more for Drools; the OptaPlanner modules; jBPM; and the Kogito runtime. The audience is Java teams that need decision logic, scheduling or process orchestration inside the JVM rather than in a separate service. The four components answer different questions. Drools is a rule engine with forward and backward chaining, a DMN decision engine, and a complex event processing engine that correlates facts over time with temporal operators and sliding windows. OptaPlanner is a constraint solver for planning problems such as vehicle routing, employee rostering and school timetabling, combining metaheuristics like tabu search and simulated annealing with incremental score calculation. jBPM is a BPMN 2.0 workflow engine for long-running, stateful processes with human tasks, timers and compensation. Kogito is the cloud-native runtime that turns DRL rules, DMN decisions and BPMN processes into microservices on Quarkus or Spring Boot. The practical boundary is that these are engines, not applications. There is no server to start and no UI in this repository. If you want a managed environment with a web console, that is a different product line, and the KIE Workbench and KIE Server names that people still search for do not appear anywhere in the README or the top-level directory listing. ## How Drools, jBPM and Kogito relate at runtime The README is explicit about the dependency direction: Kogito builds on Drools and jBPM, and it consumes the same assets they do. A DRL rule file, a DMN decision model and a BPMN 2.0 process are authored once and then either executed inside a JVM application through the Drools and jBPM engines, or compiled at build time into a runnable microservice by Kogito. That build-time code generation is the mechanism that distinguishes Kogito from running the engines directly. Rather than reading rule and process definitions at startup, Kogito generates code during the build, which the README ties to fast startup, low footprint and GraalVM native compilation. The trade-off is visible in the repository layout: the runtime is not a library you add and configure at runtime, it is a build step whose output is your service. Drools itself splits along two axes. The engine evaluates rules, and the mode of evaluation changes what the engine can do: in stream mode, facts declared as events are evaluated by the CEP engine with temporal operators and sliding windows, which is what makes fraud detection, systems monitoring and IoT scenarios possible. The other axis is the asset format. Rules can be written as DRL source or as decision tables in Excel spreadsheets, and decisions can be written in DMN with FEEL expressions. Those are not interchangeable notations; they are different authoring paths into the same engine. OptaPlanner sits apart from that pipeline. Its planning entities are plain Java classes and its constraints are written either with the Constraint Streams API or in DRL. Sharing DRL with Drools means a team already fluent in the rule language can express score rules, but the solver loop itself has nothing to do with rule firing. ## Getting the artifacts: Maven coordinates and BOMs The README states that official Apache KIE releases are source code releases, distributed from the Apache downloads page and signed with the keys listed in KEYS. For everyday use, binary artifacts are published to Maven Central under the groupIds org.kie, org.drools, org.jbpm, org.optaplanner and org.kie.kogito. There is no installer and no CLI to fetch; you consume the engines as Maven dependencies. Version management goes through a BOM. The README names three: org.drools:drools-bom, org.optaplanner:optaplanner-bom and org.kie.kogito:kogito-bom. Importing one lets you manage the versions of individual artifacts on your projects, which is the phrasing the README uses. A Drools-only project would import the Drools BOM in its dependencyManagement section, using the coordinates exactly as the README lists them, and then declare individual Drools artifacts without repeating a version. One detail in the README is easy to miss and will cost time if you do: there is no separate BOM for jBPM. Its engine runs as part of Kogito, so the org.jbpm artifacts are managed by org.kie.kogito:kogito-bom. If your process work goes through jBPM rather than Kogito, you still import the Kogito BOM to get consistent versions, and the README adds that all artifacts of a release share the same version regardless of groupId. That means 10.2.0 across Drools, OptaPlanner, jBPM and Kogito, which is convenient until you need to mix releases, at which point you are overriding individual versions by hand. For contributors rather than consumers, the Makefile is the entry point for partial builds. Its own comment says that what make dev does, the subcommands it takes and the settings it reads are all documented in docs/DEV.md, and that full builds are plain Maven, documented in docs/BUILDING.md. The Makefile defines dev as its only target and passes every other goal through DEV_ARGS to the Dev.java script unchanged and in order. ## Where the repository is thin and the incubating label matters The README is a component tour, not a getting-started guide. It documents what Drools, OptaPlanner, jBPM and Kogito are, points at kie.apache.org/documentation for their manuals, and stops. There are no quickstart snippets, no sample project, and no statement about which Java version the current release requires. Anyone arriving from a search for a download will find the downloads page and the Maven coordinates, and nothing that shows a first rule executing. The incubating status is not decorative. The repository carries a DISCLAIMER-WIP file at the root, and the README titles the project "Apache KIE (incubating)". Incubation affects release and governance processes, not the API, but it does mean the project has not yet graduated to a top-level Apache project. For a team making a multi-year commitment, that is a fact to weigh, not a blocker. Version churn is the sharper constraint. The listed releases are 10.0.0 in December 2024, 10.1.0 in July 2025 and 10.2.0 in April 2026. The README's own documentation links are version-qualified, pointing at 10.2.x, which tells you the manuals move with the release line. If you need a long support window on a fixed version, nothing in this repository describes one. There is also no documented rollback or downgrade path, and no compatibility statement covering a jump between major lines. Finally, the build story is split. The Makefile says partial builds go through make dev, whose subcommands and settings are documented in docs/DEV.md, while full builds are plain Maven, documented in docs/BUILDING.md. That is fine for contributors, but it means the repository has two build entry points and you need to know which one applies before you run anything. ## OptaPlanner versus a general-purpose solver or hand-written scheduler The realistic alternative for the scheduling half of KIE is not another rule engine. It is either a mathematical programming solver or a hand-written heuristic in your own code. The difference is in how the problem is expressed and how the search proceeds. With OptaPlanner, as the README describes it, you annotate domain classes as planning entities and write score rules with the Constraint Streams API or in DRL. The solver then combines optimization heuristics and metaheuristics such as tabu search, simulated annealing and late acceptance, and relies on incremental score calculation to avoid recomputing the whole score after every move. That structure suits problems where the constraints are numerous, heterogeneous and easier to state declaratively than to encode as a matrix. A mathematical programming approach instead asks you to linearize the problem into variables, an objective and constraints, which is a better fit when the model is naturally linear and you want a proof of optimality. A hand-written scheduler is the right answer when the problem is small enough that a greedy pass is sufficient, or when the constraint set changes so rarely that tuning a bespoke algorithm beats learning a solver's model. Choosing OptaPlanner means accepting a modeling vocabulary and a metaheuristic search that returns good solutions in reasonable time rather than guaranteed optimal ones, which is the trade the README describes for NP-hard problems. Within KIE itself there is a second choice: Constraint Streams or DRL for score rules. Picking DRL keeps one language across rules and constraints, but it also couples your solver configuration to the rule engine's semantics, so a team that only needs the solver is carrying more surface than it needs. ## Maintenance, versions and the Apache-2.0 licence The repository is not archived, and the last push was on 2026-09-20, so development is current. That says nothing about the support policy for any given release. The release cadence visible in the facts is roughly two per year, with 10.0.0, 10.1.0 and 10.2.0 spanning December 2024 to April 2026. Upgrading means moving all four component families together unless you deliberately override versions, because the README states that all artifacts of a release share the same version regardless of groupId. Kogito raises the upgrade cost further. Because it generates code at build time from DRL, DMN and BPMN assets, a version bump can change generated code in ways that only surface at build or startup. There is no migration guide in this repository, and the README does not describe one; the documentation site is where that would live, and it is versioned per release line. On licensing, the repository is Apache-2.0, and the README's own header carries the standard Apache licence notice and points at the NOTICE file for attribution requirements. Apache-2.0 includes an explicit patent grant and permits commercial and closed-source use. The one obligation worth flagging to whoever handles your notices is that redistributing the artifacts or derivative works means preserving the licence and NOTICE material. That is a general property of the licence, not a statement about your situation, and it is not legal advice. ## Conclusion Adopt Apache KIE if you need a JVM rule engine, a constraint solver, a BPMN engine or a Quarkus/Spring Boot runtime for business assets, and you are willing to pin an exact version and track the incubating status yourself. Do not adopt it expecting a single small dependency or a stable API surface across major versions: 10.0.0, 10.1.0 and 10.2.0 are the only 10.x releases listed, and the repository carries a DISCLAIMER-WIP file. Before writing code, confirm which BOM covers your artifacts, since jBPM has no BOM of its own, and read docs/DEV.md and docs/BUILDING.md to learn which build entry point applies to the modules you plan to extend. ## FAQ ### What is Apache Drools? Drools is the rule engine inside Apache KIE. The README describes it as a business rule management system with forward-chaining and backward-chaining inference, plus a DMN decision engine and a complex event processing engine that correlates facts over time with temporal operators and sliding windows. ### How do I install Apache KIE? There is no installer. The README says official releases are source code releases from the Apache downloads page, while binary artifacts are published to Maven Central under org.kie, org.drools, org.jbpm, org.optaplanner and org.kie.kogito, with versions managed by importing drools-bom, optaplanner-bom or kogito-bom. ### Which BOM should I import for jBPM artifacts? The Kogito BOM. The README states there is no separate BOM for jBPM because its engine runs as part of Kogito, so the org.jbpm artifacts are managed by org.kie.kogito:kogito-bom. ### Do I need to install Quarkus or Spring Boot to use Apache KIE? Only for Kogito. The README describes Kogito as the cloud-native runtime available for Quarkus and Spring Boot, while Drools, OptaPlanner and jBPM are Java engines you can use directly from Maven dependencies. ### Is Apache KIE the same as KIE Workbench or KIE Server? Neither name appears in the README or in the repository's top-level entries. The README covers Drools, OptaPlanner, jBPM and Kogito only, so a managed server or web console is not part of what this repository documents. ## Sources - [apache/incubator-kie on GitHub](https://github.com/apache/incubator-kie) - [License: Apache-2.0](https://github.com/apache/incubator-kie/blob/main/LICENSE) - [Project website](https://kie.apache.org) - [README](https://github.com/apache/incubator-kie/blob/main/README.md) - [Releases](https://github.com/apache/incubator-kie/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/apache-incubator-kie