Hi,
I am only following this list and not really looking actively at the
code, but I was wondering if the maven build uses the enforcer plugin,
especially the dependencyConvergence option:
https://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html
I had a short look at some, but did not find anything...and there a lot
of poms
Of course that would not prevent the Quarkus / Spring Boot problem of
requiring different versions. But if SpringBoot depends on jackson 3.x
and kogito-jackson-utils on 2.x and the SpringBoot module uses
kogito-jackson-utils, then the build should fail with this option.
This does not replace a reorganization of the BOMs of course.
bye Jochen
On 4/30/26 16:10, Yeser Amer 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]
