Hi Alex, thank you for your feedback. Thank you for raising this important point about independent framework upgrades. Let me clarify how this proposal addresses exactly this concern.
The ability to perform independent framework upgrades is one of the main problems this proposal solves. We're currently experiencing this challenge firsthand with the Spring Boot 4 upgrade (https://github.com/apache/incubator-kie-issues/issues/2288), where we're struggling to find versions of Jackson and Netty that are compatible with both Quarkus 3.27.2 and Spring Boot 4. With this proposal, while most dependency versions will be declared in kie-parent, the framework-specific BOMs (kogito-quarkus-bom and kogito-spring-boot-bom) will be able to override these versions when necessary. This means: - Shared dependencies (like Jackson, Netty, Reactor) will have a baseline version in kie-parent - Framework-specific overrides can be declared in kogito-quarkus-bom or kogito-spring-boot-bom when the framework requires a different version - Modules depending on a specific framework will inherit the appropriate version through their framework-specific BOM parent This approach eliminates the current situation where we must find a single version that satisfies both frameworks simultaneously—a constraint that often blocks upgrades entirely. Instead, each framework can use the version it requires, and only the framework-agnostic modules in kie-parent need to work with a common baseline. I realize that this key aspect was not properly highlighted in the proposal; hopefully, it is clearer now. Thanks, Yeser On 2026/04/30 16:03:18 Alex Porcelli wrote: > Thanks, Yeser, Gabriele, and Chinchu, for taking this on. The > diagnosis is mostly right: the duplication, the empty framework BOMs, > and the convergence issues are real. > > A few concerns, though: > > Timing. We are mid-consolidation for 10.3.x under Tiago's plan, across > the same repos. Running a structural BOM rework in parallel will fight > for review bandwidth and make regressions hard to bisect. Strong > preference to finish 10.3.x first. > > Scope. This bundles at least four independent changes (dedup, empty > BOMs, kie-parent split + enforcer rules, kogito-apps reorg). Each has > a different risk and reviewers. Could we split into separate > proposals? I can get behind some of them on their own, but not as one > package. > > Independent framework upgrades. Not convinced this holds up. Shared > deps like Jackson, Netty, and Reactor are pulled by both Quarkus and > Spring Boot at different versions. If they live in kie-parent, BOM > import ordering decides who wins, and the proposal does not specify > it. Most CVEs hit shared transitive deps anyway, so cross-framework > coordination does not really go away. A worked example through a > recent CVE would help. > > Happy to support smaller, focused proposals after 10.3.x lands. > > - > Alex > > On Thu, Apr 30, 2026 at 10:12 AM Yeser Amer <[email protected]> wrote: > > > > 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. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
