Hi Apache KIE community, Long-time contributors know how time‑consuming it can be to upgrade Kogito's required frameworks, such as Quarkus and Spring Boot. This activity is both critical and recurring, yet based on our experience it often requires a significant and unpredictable amount of effort.
Given how frequently we need to perform these upgrades, we believe it's time to improve the process. We would like to propose a set of changes to the current BOM management approach, based on lessons learned from past upgrades across the KIE ecosystem. We welcome any opinions and feedback from the community. To better understand the proposed changes, please review the draft PRs that demonstrate the implementation. We encourage discussion and collaboration on these PRs to refine the approach. For tracking and coordination, please refer to the main issue: https://github.com/apache/incubator-kie-issues/issues/2029. Here, you can find the open PRs ready to be reviewed. The goal of this initiative is to: - reduce the overall time spent on framework upgrades, - make the process more predictable and consistent, - enable both current and future maintainers to complete these tasks in days rather than weeks, - allow each framework to be upgraded independently, without worrying about transitive dependency conflicts, - apply CVE fixes faster without cross-framework coordination. The proposed changes will impact the following repos: - drools - kogito-runtimes - kogito-apps - kogito-examples - kie-tools Current Status of BOM Management drools: - build-parent/pom.xml: This module currently acts as the main BOM, managing both the third-party dependencies and the internal dependency declarations. It also defines Quarkus (and likely several Quarkus‑related dependencies). Three main issues have been identified: 1. Framework coupling: The drools repo should be "cloud-native framework agnostic"; Quarkus and related specific dependencies should not be declared here. 2. Mixed responsibility inside the BOM: Internal project dependencies and external third‑party dependencies are currently managed within the same BOM. This makes version alignment, troubleshooting, and framework upgrades harder to reason about, and increases the risk of unintended side effects during dependency updates. 3. Scattered dependency declarations across submodules: Not all third‑party dependencies are declared in the main BOM; some are managed directly within individual submodules. This fragmentation makes it more difficult to track, align, and update dependencies consistently across the codebase. kogito-runtimes: - kogito-dependencies-bom/pom.xml: Acts as the main BOM for Kogito runtime projects, declaring third‑party dependencies required for cloud‑native applications (e.g. Quarkus, Spring Boot, and related libraries). - kogito-quarkus-bom/pom.xml: Intended to manage third‑party dependencies specific to Quarkus‑based Kogito applications. - kogito-spring-boot-bom/pom.xml: Intended to manage third‑party dependencies specific to Spring Boot‑based Kogito applications. Main issues identified: 1. Unused framework‑specific BOMs: Despite the presence of both kogito-quarkus-bom and kogito-spring-boot-bom, which are intended to manage Quarkus and Spring Boot dependencies respectively, these BOMs are effectively empty and not used for their intended scope. As a result, framework‑specific dependencies are still being managed elsewhere, defeating the purpose of having dedicated BOMs. 2. Duplication of third‑party dependency declarations: A significant portion of the third‑party dependencies declared in kogito-dependencies-bom duplicates dependencies already declared in drools/build-parent/pom.xml. This duplication is unnecessary and increases the risk of: version misalignment, dependency conflicts, higher maintenance costs (e.g. CVE fixes and coordinated upgrades). kogito-apps: The kogito-apps repository does not currently define its own BOM to manage third-party dependencies. However, the existing project structure limits the ability to take advantage of the framework‑specific BOM split already present in the kogito-runtimes repository. The applications are organized by feature rather than by framework, using the following structure: kogito-apps/feature+ common-impl+ quarkus-impl+ spring-boot-impl kie-tools: This repository has a Maven module acting as a BOM, maven-base. It already imports kogito-apps-bom, together with additional unnecessary KIE BOMs. As a result, Quarkus-specific dependencies are mixed into a shared dependency management layer. Problems to Solve - The same dependency is declared with different versions in "parent" and "children" modules - The same dependency is inherited transitively in some modules but explicitly declared in others - At the bottom of the stack (final applications/examples) there are multiple convergence issues - Wrong behavior often appears at runtime rather than compile time, making it hard to detect Proposed Changes drools: - Introduce a new kie-parent/pom.xml BOM: A new kie-parent module will be introduced as the only place where third-party dependencies are declared. This BOM will be used throughout the KIE ecosystem. All identified Quarkus‑related dependencies will be excluded from this BOM, keeping it framework agnostic. - Introduce a new kie-parent-drools/pom.xml BOM: A new kie-parent-drools module will be introduced as a BOM aggregator for first-party Drools dependencies (internal Drools modules). This separates first-party dependency management from third-party dependencies in kie-parent. - Refocus drools-build-parent/pom.xml responsibilities: The existing drools-build-parent/pom.xml will be refocused to keep build configuration and plugin management only. It will no longer manage first-party dependencies (moved to kie-parent-drools) and will no longer declare third-party dependencies directly. It will inherit from kie-parent-drools. - Remove all <dependencyManagement> from submodules: All submodules will inherit dependency versions from kie-parent, with no local overrides allowed. - Enforce centralized dependency management: Two new enforcer rule modules will be introduced: - kie-no-dependency-management-enforcer-rule: Enforces a "no dependencyManagement" rule within Drools submodules. Submodules will no longer be allowed to declare their own <dependencyManagement> sections, not even inside profiles. This prevents the anti‑pattern of declaring dependency versions outside the main BOM. Exceptions will be allowed only for well‑justified and explicitly approved cases via the <allowedPomsList> property. - kie-no-external-managed-dependency-enforcer-rule: Blocks dependency management entries for external artifacts not part of the current multi-module project. This keeps managed dependencies limited to the project's own modules and prevents accidentally pulling in or controlling versions of unrelated external libraries. - Isolate Quarkus‑specific build logic: A new module, kie-quarkus-build-parent, will be introduced to extend kie-parent for the only allowed Quarkus‑related module within Drools ( drools-quarkus-extension). This exception is retained for historical reasons (Drools has a dependency on Quarkus). It extends rather than imports to also inherit pluginManagement. See diagram: https://github.com/user-attachments/assets/7db5e9be-213d-4d86-804f-e1f1cffb50d3 kogito-runtimes: - Remove kogito-dependencies-bom: Deleted as it's no longer needed; functionality replaced by inheriting directly from drools/kie-parent through the parent hierarchy, eliminating duplication of third-party dependency declarations. - Modify kogito-bom: Existing BOM module, now inherits from drools/kie-parent-drools, aggregating kogito-specific dependency management. - Modify kogito-runtime-bom: Existing runtime BOM, now inherits from drools-build-parent for configuration build setting import. - Modify kie-kogito-bom: Existing KIE-Kogito integration BOM, now inherits from drools-build-parent. - Populate kogito-quarkus-bom: Existing but previously unused BOM now populated with all Quarkus-specific dependencies; inherits from kogito-build-no-bom-parent; inherited by kogito-apps-quarkus. - Populate kogito-spring-boot-bom: Existing but previously unused BOM now populated with all Spring Boot-specific dependencies; inherits from kogito-build-no-bom-parent; inherited by kogito-apps-spring-boot. - Remove all <dependencyManagement> from submodules: All submodules inherit dependency versions from their parent BOMs. - Uniform checks with drools repository: Apply the same enforcer rules and patterns used in drools. See diagram: https://github.com/user-attachments/assets/90f80d70-2300-4d8a-901a-330807039440 kogito-apps: - Regroup applications by framework instead of by feature: The current feature‑centric structure will be reorganized to be framework‑centric. Specifically, two top‑level, framework‑specific modules will be introduced: kogito-apps-quarkus and kogito-apps-spring-boot. All framework‑specific application modules will be moved under their respective top‑level framework module. See diagram: https://github.com/apache/incubator-kie-issues/issues/2029#kogito-apps-diagram kogito-examples: The kogito-examples repository will receive only minimal changes required to work with the main changes applied in upstream repositories. The main changes are: the POM file of the Quarkus examples module will import the kogito-apps-quarkus-bom BOM and the Spring Boot examples module will import the kogito-apps-spring-boot-bom BOM. kie-tools: - Keep maven-base as the shared base BOM, but clean it up by removing unnecessary dependencies and BOM imports already covered by kie-parent (drools). - Create maven-quarkus-bom and maven-spring-boot-bom to manage Quarkus and Spring Boot dependencies separately. - Make leaf modules inherit from the appropriate framework-specific BOM according to their runtime framework. See diagram: https://github.com/user-attachments/assets/06f8362a-092d-40bb-8a01-3560c41a4a8e Kudos to Gabriele Cardosi, who is driving this important initiative and to Chinchu P Shaji for her support.
