Hello everybody! We would like to inform you that PRs have been merged. Thanks to everyone who participated and shared their opinions and feedback. We plan to keep improving defects and other details that we found and will appear in the future.
Thanks again! Best Gabriele On Mon, May 18, 2026 at 10:06 AM Gabriele Cardosi < [email protected]> wrote: > 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] >> >>
