HI Alex, thanks for the feedback, I'm glad now things are clearer. About "bom-consolidation" (i.e., IIUC, group and collapse framework-specific boms) there is an issue behind that I wanted to solve and it is not dependent on repo structure. I discovered that some not-existing modules were still declared in some poms. At the same time, some kogito-apps modules were declared inside the kogito-runtimes ones. The problem with this approach is to have an "blind" binding, i.e. the "kogito-runtimes" (or any other one project) needs to have knowledge of a downstream project (kogito-apps is downstream for kogito-runtimes regardless of the repo structure, as kogito-runtimes is downstream for drools project). This is the "pom" realization of an anti-pattern that goes against the clean-architecture principles. The "no-external-dependency-management" enforcer rule has been implemented exactly to forbid this "anti-pattern", and that is why, IMO, it would make sense to keep project-framework-specific poms.
I hope this would make sense. Cheers Gabriele On Sat, May 16, 2026 at 10:27 PM Alex Porcelli <[email protected]> wrote: > The new framing makes this easier to engage with, and scoping out the > dual-framework lock-in is the right call. Dedup, single source of > truth, and enforcer rules are useful on their own. No objection from > my side. > > One thought. The PRs put framework BOM pieces (kogito-quarkus-bom, > kogito-spring-boot-bom, plus extensions in kogito-apps, kie-tools, > examples) into every existing repo. With the consolidation work > coming, most of those will end up in the same reactor anyway, and the > extension layers being added now will likely need to be collapsed. > > If consolidation is close on the roadmap, might be worth shaping > things around the future two-repo layout from the start: common plus > framework BOMs in the unified kie repo, a similar set in Tools. Same > destination, less churn. > > - > Alex > > On Thu, May 14, 2026 at 4:55 PM Tiago Bento <[email protected]> wrote: > > > > I am glad to see movement on improving our dependency management. Even > > though it might not solve all the historical problems, I am supportive > > of iterative efforts like the ones this initiative brings. Thanks > > Gabriele, Yeser and others for all the work you've put into > > understanding the current (convoluted) structure we have, and for not > > only helping maintain the dependencies up-to-date in the past, but > > also for pushing for a higher quality bar now. Hope these changes make > > it easier to address foundational library upgrades such as Quarkus and > > Spring Boot, and also help enforce good practices when dealing with > > the (inevitable in the current structure) conflicts that supporting > > those two frameworks bring. > > > > On Wed, May 13, 2026 at 11:48 PM Toshiya Kobayashi > > <[email protected]> wrote: > > > > > > Thank you very much for the great effort, Gabriele. > > > > > > I left a few minor comments on the Drools PR, but overall the > > > direction looks good. > > > > > > Toshiya > > > > > > On Wed, May 13, 2026 at 9:53 PM Jijo Thomas K via dev > > > <[email protected]> wrote: > > > > > > > > > > > > For the Quarkus upgrade (to 3.27.x) activity we lastly worked on, we > clearly felt the challenge of not having proper dependency management in > place. Although the upgrade effort was initially scoped only for Quarkus, > tight coupling in the POM required us to upgrade Spring Boot at the same > time. One major conflict we faced was Hibernate compatibility, which > required custom Spring-specific code to bridge version gaps. This proposal > directly addresses those pain points by centralizing dependency management > and separating framework hierarchies, helping prevent the cascading upgrade > issues we experienced. A clear BOM structure will eliminate future version > conflicts and significantly reduce maintenance overhead. > > > > > > > > Thanks for this wonderful effort, Gabriele. Special thanks as well > to Yeser Amer and Chinchu P Shaji for their collaboration in making the KIE > codebase more maintainable. > > > > > > > > Jijo > > > > > > > > From: Yeser Amer <[email protected]> > > > > Date: Wednesday, 13 May 2026 at 1:00 PM > > > > To: [email protected] <[email protected]> > > > > Subject: [EXTERNAL] Re: [HEADS-UP] Dependency management > simplification > > > > > > > > Thank you, Gabriele, for the effort you put into moving our codebase > forward and improving its maintainability. > > > > > > > > On 2026/05/12 15:44:25 Gabriele Cardosi wrote: > > > > > We realized that the previous version (1) of the proposal did not > > > > > accurately reflect the real motivation behind the proposed > changes. As a > > > > > result, it created unjustified expectations about both its goals > and > > > > > non-goals. For this reason, we have decided to reframe the > proposal by > > > > > renaming its title and providing a new description that better > clarifies > > > > > its objectives. > > > > > > > > > > Context > > > > > The KIE codebase is composed, broadly, of two kinds of components: > > > > > > > > > > > > > > > 1. Common code (utility libraries, engine modules) > > > > > 2. Framework-specific code (Quarkus/Spring Boot) that exposes > the above > > > > > and, eventually, adds framework-specific behavior > > > > > > > > > > > > > > > If an external dependency is used at both the common and > framework-specific > > > > > levels, a lock-in occurs—i.e., the versions of the library used at > both > > > > > levels must be compatible at both compile-time and runtime. > > > > > Since we are exposing common code through two different frameworks > (Quarkus > > > > > and Spring Boot), this also implies that there must be > compile-time and > > > > > runtime compatibility of dependency versions across the two > frameworks. > > > > > This situation applies only to dependencies used at both the > common and > > > > > framework levels. We refer to it as *dual-framework lock-in*, an > > > > > architectural issue inherent in the design of our codebase. > > > > > *The current proposal does not aim to address this issue, as its > solution > > > > > is outside the scope of this discussion.* > > > > > > > > > > There are, however, other dependencies that are used only at one > level > > > > > (either common or framework-specific). For these dependencies, > such lock-in > > > > > does not exist, even if the library is used in both frameworks, > provided it > > > > > is not used at the common level. The current proposal aims to > simplify the > > > > > management of these dependencies. > > > > > While the above describes the architectural design—which is > independent of > > > > > language and build tools—there is also the implementation aspect. > > > > > > > > > > Currently, dependency versions are scattered across multiple POMs > in > > > > > different projects (Drools, Kogito Runtimes, OptaPlanner, Kogito > Apps, > > > > > Kogito Examples). Sometimes a dependency version is overridden or > declared > > > > > in specific submodules; sometimes versions used at framework > levels clash, > > > > > and often it is unclear why a given version is inherited in the > final > > > > > application. > > > > > > > > > > Other issues include: > > > > > > > > > > - Version declarations for KIE artifacts that no longer exist > (e.g., in > > > > > Drools) > > > > > - Version declarations for KIE artifacts defined in downstream > projects > > > > > (e.g., in Kogito Runtimes, there are declarations for Kogito > Apps > > > > > artifacts), creating a violation of clean architecture > principles > > > > > > > > > > > > > > > All of this makes dependency maintenance difficult, error-prone, > and > > > > > time-consuming. > > > > > A notable example is CVE fixes, which currently must be applied in > at least > > > > > three (or sometimes more) places. Even more problematic are > framework > > > > > upgrades, which are affected not only by the dual-framework > lock-in but > > > > > also by overrides that must be applied in multiple places—sometimes > > > > > unexpectedly, as observed during the last Quarkus upgrade. > > > > > > > > > > Scope > > > > > The scope of this proposal is to simplify our dependency management > > > > > structure and reduce the issues listed above. > > > > > The proposed solution aims to define only three sets of BOMs: > > > > > > > > > > - One for common code and external dependencies > > > > > - One for Quarkus > > > > > - One for Spring Boot > > > > > > > > > > > > > > > It also introduces a clear and unambiguous POM hierarchy that > ultimately > > > > > converges to a single parent. > > > > > With this structure, navigation from any low-level POM to the > top-level one > > > > > becomes straightforward, making it easy to identify where changes > must be > > > > > applied. Additionally, it becomes simpler to determine beforehand > which POM > > > > > needs modification under different scenarios. > > > > > > > > > > Approach > > > > > Three main principles guide this proposal: > > > > > Architectural Level > > > > > > > > > > - Enforce separation between the two framework-specific POM > hierarchies > > > > > - Ensure all external dependency declarations converge into a > single POM > > > > > > > > > > > > > > > Design Level > > > > > > > > > > > > > > > - Centralize version declarations into three well-defined BOMs > > > > > - Define the top-level POM (kie-parent, in the Drools project) > to > > > > > contain all external dependency declarations > > > > > - For Quarkus: use kogito-quarkus-bom (in Kogito Runtimes) as > the > > > > > top-level BOM > > > > > - Note: this already exists but is currently incomplete > > > > > - For Spring Boot: use kogito-spring-boot-bom (in Kogito > Runtimes) as > > > > > the top-level BOM > > > > > - Note: this already exists but is currently incomplete > > > > > - In downstream projects, create framework-specific BOMs that > extend > > > > > upstream ones, adding only project-specific modules > > > > > - Ensure a clear parent-child hierarchy that ultimately > converges to > > > > > kie-parent > > > > > - Remove or block dependencyManagement tags in all POMs except > the > > > > > designated BOMs > > > > > - Apply consistent enforcer rules across the entire codebase > > > > > > > > > > > > > > > Implementation Level > > > > > Introduce two enforcer rules: > > > > > > > > > > - no-dependency-management-tag: prohibits POMs from declaring > > > > > dependencyManagement sections, preventing duplication and > accidental > > > > > version declarations > > > > > - no-external-managed-dependency-rule: prevents POMs from > declaring > > > > > versions for modules outside the current project, avoiding > references to > > > > > obsolete or external artifacts > > > > > > > > > > > > > > > With these rules in place, the following benefits are achieved: > > > > > > > > > > CVE fixes require changes in a single POM, easily located by > traversing the > > > > > hierarchy to kie-parent > > > > > Framework-specific overrides also require modifications in a > single, > > > > > clearly defined POM > > > > > Arbitrary version declarations are prevented, improving long-term > > > > > maintainability > > > > > Documentation (README files and comments) clarifies where and how > version > > > > > updates should be applied > > > > > > > > > > > > > > > Recap > > > > > In conclusion, this proposal provides the following benefits: > > > > > > > > > > - Centralized version management (single source of truth) > instead of > > > > > scattered definitions > > > > > - Reduced duplication and elimination of unnecessary overrides > > > > > - Clear separation between Quarkus and Spring Boot hierarchies > > > > > - A consistent, linear POM hierarchy converging on kie-parent > > > > > - Simplified overrides for framework-specific dependencies > > > > > - Strong architectural governance over version management > > > > > - Prevention of invalid or outdated dependency declarations > > > > > > > > > > Kudos to Yeser Amer and Chinchu P Shaji for their collaboration > and support. > > > > > > > > > > --- > > > > > 1: > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.apache.org_thread_h0gpsvtxxdqq6mt9t1dnjn3s43kd0h3s&d=DwIFaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=chE-O7gziZQiZi9dvpCs_NiJukBA2SJazsOwhCN4Zr4&m=V1iWvOiM9D2WjiCaKr5H9L9WbIGI52Sjowhe7_6gSqRMW1v5oGi9sBcT970JOEti&s=GSuJpVBhn3hgBMrCiM8vQ_4zveOTkRwJAtgJUKJEEn0&e= > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > 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] > > > > > > > --------------------------------------------------------------------- > > 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] > >
