org.jbpm与org.kie.kogito版jBPM的区别及选型咨询

核心定位差异 #

• org.jbpm：这是传统jBPM项目的核心构件集合，专注于提供成熟稳定的企业级BPMN2流程引擎能力，是KIE生态的基础组件。它的设计侧重传统单体/集群部署场景，提供完整的流程执行、任务生命周期管理、规则引擎集成等核心功能，没有绑定云原生相关的附加能力。
• org.kie.kogito：这是KIE生态针对云原生场景重构的流程引擎实现，基于jBPM核心代码演进而来。它主打轻量、事件驱动、Serverless友好，除了BPMN2支持外，默认集成了Quarkus微服务框架、事件流适配、决策管理、Serverless部署适配等大量云原生附加功能，目标是适配微服务、云原生架构。

Maven构件差异的本质 #

虽然两者都依赖org.kie父POM，但构件拆分逻辑完全服务于各自的定位：

• org.jbpm的构件按核心功能拆分（如jbpm-core、jbpm-bpmn2、jbpm-human-task），每个构件只聚焦单一流程相关能力，依赖树精简可控，不会引入无关组件。
• org.kie.kogito的构件按云原生场景打包（如kogito-runtime、kogito-bpmn-quarkus），即使只引入BPMN相关构件，也会默认带上Quarkus、事件驱动等云原生依赖，整体依赖体积和复杂度更高。

选型建议（仅需BPMN2流程流，无需Kogito附加功能） #

直接选择org.jbpm，原因如下：

1. 依赖更精简：仅引入流程引擎核心依赖，没有多余的云原生组件，降低部署包体积和依赖冲突概率。
2. 完全满足需求：org.jbpm对BPMN2标准的支持完整覆盖流程编排、网关、用户任务、事件触发等核心场景，足以支撑纯流程流的业务需求。
3. 学习维护成本更低：无需学习Kogito的云原生附加概念，只需要专注于流程引擎本身的使用和配置即可。

内容的提问来源于stack exchange，提问作者Eugene de Lange