It’s happening today mostly “by accident” (when on purpose a dependency is overridden in spring boot component).
The proposal makes the issue an architectural issue. On Thu, May 7, 2026 at 10:07 AM Yeser Amer <[email protected]> wrote: > Hi Alex, > I've carefully gone through your message, and I see the concern you're > raising. You're highlighting that these framework‑agnostic modules are > built once against a single Jackson version, but then reused across > different runtimes, which means the effective version can diverge depending > on how dependencies are resolved. > In the first case, you're pointing out how a major version shift—like > Jackson 2 to 3—creates a clear break, where code compiled against one API > ends up referencing classes that no longer exist at runtime. So even though > everything builds successfully, it fails later when those assumptions no > longer hold. > In the second case, you're calling out a more subtle situation, where > different minor versions of related Jackson components end up coexisting on > the classpath. That doesn't immediately break anything, but it introduces > differences in behavior that are hard to detect and reason about—and as you > noted, this is already happening in the repository today. > > On 2026/05/07 11:52:28 Alex Porcelli wrote: > > This is a concrete walk-through that shows my concern. > > > > About 200 files in framework-agnostic modules, including > > api/kogito-api, api/kogito-events-core, > > kogito-workitems/kogito-jackson-utils, and ~10 modules under > > addons/common/*, directly import com.fasterxml.jackson.*. They compile > > once in the single-reactor build against the kie-parent Jackson > > version, and their JARs are consumed by both Quarkus runtimes > > (kogito-quarkus-common, quarkus/addons/process-management/runtime, > > etc.) and Spring Boot starters (springboot/starters, > > springboot/addons/process-svg, etc.). > > > > Two failure modes the override mechanism doesn't prevent: > > > > 1. Major-version skew, loud, but at the wrong time. Jackson 2 -> 3 is > > a package rename (com.fasterxml.jackson.* → tools.jackson.*). If the > > SpringBoot BOM overrides to 3.x, the bytecode in kogito-jackson-utils > > still references com/fasterxml/jackson/databind/ObjectMapper, a symbol > > that doesn't exist in 3.x. NoClassDefFoundError at link time, not > > compile time. Build green, runtime broken. > > > > 2. Minor-version skew, silent, and the dangerous one. Already > > happening in the repo today. In > > > quarkus/integration-tests/integration-tests-quarkus-processes-persistence/integration-tests-quarkus-processes-postgresql, > > mvn dependency:tree shows jackson-jakarta-rs-json-provider:2.21.1 > > (pinned by kogito-dependencies-bom) and jackson-jakarta-rs-base:2.19.2 > > (transitive from quarkus-bom 3.27.3, not declared by > > kogito-dependencies-bom) resolving simultaneously into the same > > classpath. Two sibling artifacts of the same Jackson sub-package, two > > different minors. It compiles, it links, it runs. Behavior between > > Jackson minors shifts in non-trivial ways: default unknown-property > > handling, JSR-310 timezone parsing, polymorphic deserialization edge > > cases. The framework-override pattern multiplies this surface, because > > a BOM only governs what it explicitly declares, and every artifact it > > omits is decided by whichever upstream BOM happens to be imported > > first. > > > > On Thu, May 7, 2026 at 6:07 AM Deepak Joseph <[email protected]> > wrote: > > > > > > I strongly support the BOM splitting initiative proposed by Gabriele > and > > > Yeser. +1 > > > > > > The real value here goes beyond code organization—this proposal > directly > > > addresses the time-consuming framework upgrades we've all experienced, > > > enables faster security patching, and creates a more maintainable > codebase > > > for everyone working on these projects. > > > > > > Regards, > > > Deepak Joseph > > > > > > > > > On Thu, May 7, 2026 at 3:29 PM Chinchu P Shaji via dev < > [email protected]> > > > wrote: > > > > > > > Hi Alex, > > > > > > > > Thank you for taking the time to review the proposal and share your > > > > concerns. I’d like to add few points and will try to provide a > couple of > > > > concrete examples of how this approach helps with upgrades: > > > > > > > > * > > > > Spring Boot 4 upgrade case: Now aligning Jackson and Netty versions > across > > > > both Quarkus and Spring Boot requires finding a single “compromise” > version > > > > that works everywhere. With the proposed split, Quarkus modules can > > > > continue to use Jackson 2.19.x while Spring Boot modules adopt > Jackson 3.x. > > > > The common BOM provides a baseline, but framework-specific BOMs > override > > > > where necessary. This avoids blocking one framework’s upgrade > because of > > > > the other. > > > > * CVEs and transitive dependencies: When a CVE hits a shared > library > > > > like Reactor, the fix often comes at different versions depending on > the > > > > framework. Under the current structure, overrides are scattered > across > > > > multiple POMs, making it hard to track. With the new hierarchy, the > > > > override is centralized in the framework BOM, so Quarkus and Spring > Boot > > > > can each patch independently without breaking the other. > > > > * Maintenance clarity: During the Quarkus migration, overrides > had to > > > > be applied in unexpected places, leading to confusion about which > version > > > > was actually in use. The proposed enforcer rules and BOM hierarchy > make > > > > version inheritance explicit, reducing the risk of hidden conflicts > and > > > > simplifying future upgrades. > > > > > > > > In short, the proposal doesn’t eliminate the fundamental challenge of > > > > frameworks pulling different versions, but it does make upgrades more > > > > manageable by isolating framework-specific needs while keeping a > clear > > > > common baseline. > > > > > > > > Thanks again for your thoughtful review. I believe this > restructuring will > > > > reduce friction and make future upgrades less painful for everyone. > > > > > > > > > > > > Thanks, > > > > Chinchu P Shaji > > > > > > > > From: Alex Porcelli <[email protected]> > > > > Date: Wednesday, 6 May 2026 at 5:16 AM > > > > To: [email protected] <[email protected]> > > > > Subject: [EXTERNAL] Re: [HEADS-UP] Enforce framework-specific BOM > > > > separation > > > > > > > > I reviewed the PRs, and although I understand the intention behind > > > > them, in practice, I could only see shuffling things around and a bit > > > > of scope creep (some cleanup being done). > > > > > > > > Don't get me wrong, I can see the benefits of deduplication in > > > > kogito-dependencies-bom, but this is a large change, and I still > > > > struggle to see how it will help with upgrades. > > > > > > > > Please provide a couple of practical examples on how this will help > > > > with the upgrades. > > > > > > > > > > > > On Tue, May 5, 2026 at 6:50 AM Pere Fernandez (apache) > > > > <[email protected]> wrote: > > > > > > > > > > Thank you very much for this effort Gabriele and Yeser! I had to > deal > > > > with > > > > > some Quarkus and Spring upgrades in the past and aligning versions > > > > between > > > > > both frameworks can be a nightmare and I think this initiative will > > > > > definitely help there. > > > > > > > > > > I'll give an eye to the PRs and will try to provide some feedback > ASAP. > > > > > > > > > > Cheers! > > > > > > > > > > Pere > > > > > > > > > > > > > > > > > > > > On Fri, 1 May 2026 at 07:52, Gabriele Cardosi < > > > > [email protected]> > > > > > wrote: > > > > > > > > > > > Yes, Alex, the issue you mention is clear and we considered it. > > > > > > But that issue depends on the overall architecture and already > exists, > > > > > > nevertheless. > > > > > > The scope of this proposal is not to fix that, but to simplify > and > > > > reduce > > > > > > the burden of maintenance. Currently, de facto, the "common" > versions > > > > get > > > > > > aligned with quarkus, and if by chance there is some > incompability with > > > > > > springboot, we have to identify lot of multiple places to make > > > > overrides, > > > > > > sometime at unexpected level. Any framework update requires long > and > > > > hard > > > > > > work to be done in all the different poms in the codebase, and > the same > > > > > > goes true for CVEs. There is a big chance of version clashing, > and it > > > > is > > > > > > not even clear, in the final kogito application, why and how some > > > > version > > > > > > gets inherited. I've helped recently with the quarkus migration, > and I > > > > saw > > > > > > multiple of those strange side-effects. > > > > > > This proposal try to address all the above issues, and in case > you did > > > > not > > > > > > already, I would suggest you to take a deeper look at the > enforcers > > > > > > introduced, at the seamless pom navigation, and at the > straightforward > > > > > > maintenance tasks that this approach lead to. > > > > > > > > > > > > Cheers! > > > > > > > > > > > > Il Ven 1 Mag 2026, 00:23 Alex Porcelli <[email protected]> ha > scritto: > > > > > > > > > > > > > Thank you for the clarification, Gabriele. > > > > > > > > > > > > > > I love the idea, but I'm struggling with how this would work in > > > > > > > practice. Let's be pragmatic: > > > > > > > > > > > > > > Jackson: > > > > > > > - Quarkus is 2.19.x > > > > > > > - SpringBoot 4 uses 3.x > > > > > > > > > > > > > > What do we select for common? How to make 2.19 and 3.x work in > the > > > > > > > same codebase? > > > > > > > > > > > > > > > > > > > > > On Thu, Apr 30, 2026 at 4:37 PM Gabriele Cardosi > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > Hi Alex, > > > > > > > > with this proposal the hierarchy of the framework-specific > modules > > > > is > > > > > > > > completely separated. > > > > > > > > There is (in abstract terms) > > > > > > > > one bom for all external/common libraries > > > > > > > > one bom for quarkus modules > > > > > > > > one bom for springboot modules > > > > > > > > Framework-specific boms *inherit* (*not import!*) the common > one: > > > > i.e. > > > > > > > the > > > > > > > > "common bom" is the parent of the framework-specific ones. > > > > > > > > So, at framework-specific bom level, it is possible to > override the > > > > > > > version > > > > > > > > inherited from the parent. > > > > > > > > At the same time, for a given library, it is possible to > have one > > > > > > version > > > > > > > > for the quarkus hierarchy and a different version for the > > > > springboot > > > > > > one. > > > > > > > > > > > > > > > > Please note that I wrote "one bom" only to simplify and make > clear > > > > the > > > > > > > > concept behind. > > > > > > > > > > > > > > > > I hope this would make sense and clarify your doubts. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Apr 30, 2026 at 7:38 PM Alex Porcelli < > [email protected] > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > I might have gotten lost in the length of the proposal, so > > > > apologies > > > > > > > > > if I missed it. I am still not sure how the isolation > actually > > > > helps > > > > > > > > > with the Spring Boot 4 upgrade case you mentioned. There > are > > > > several > > > > > > > > > shared libraries used in common implementations (Jackson > being > > > > the > > > > > > > > > obvious one), where the conflict between frameworks does > not > > > > seem to > > > > > > > > > go away. > > > > > > > > > > > > > > > > > > Could you walk through, in simplified terms, how the > proposal > > > > > > > > > addresses this in both the common and framework-specific > > > > codebases? > > > > > > > > > > > > > > > > > > On Thu, Apr 30, 2026 at 12:45 PM Yeser Amer < > [email protected]> > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_incubator-2Dkie-2Dissues_issues_2288&d=DwIFaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=Q6vLAuW9efZUIpzkybJzdGQcnEzNk9UeYj-IzYzMKJA&m=Kiy4P6Klmdyqr20NoQqQ7jSQDgF2YyY_4MvwC2D6AfAWMCrtcJj5S-7UEadYn7fs&s=N4g4C6DJeQZTYhIz-JkFxS_8_4NfWiJiyV53n9w2FCs&e= > > > > ), 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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_incubator-2Dkie-2Dissues_issues_2029&d=DwIFaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=Q6vLAuW9efZUIpzkybJzdGQcnEzNk9UeYj-IzYzMKJA&m=Kiy4P6Klmdyqr20NoQqQ7jSQDgF2YyY_4MvwC2D6AfAWMCrtcJj5S-7UEadYn7fs&s=dDqrPHf89L7L1BVAX4pC0y0LDPrJI9Z8SIm5JKnwQaY&e= > > > > . > > > > > > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_user-2Dattachments_assets_7db5e9be-2D213d-2D4d86-2D804f-2De1f1cffb50d3&d=DwIFaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=Q6vLAuW9efZUIpzkybJzdGQcnEzNk9UeYj-IzYzMKJA&m=Kiy4P6Klmdyqr20NoQqQ7jSQDgF2YyY_4MvwC2D6AfAWMCrtcJj5S-7UEadYn7fs&s=ZQl3dyInEw-RDu-Qb_i2bbBTp9WmseB-TE5iqnxNX-A&e= > > > > > > > > > > > > > > > > > > > > > > > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_user-2Dattachments_assets_90f80d70-2D2300-2D4d8a-2D901a-2D330807039440&d=DwIFaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=Q6vLAuW9efZUIpzkybJzdGQcnEzNk9UeYj-IzYzMKJA&m=Kiy4P6Klmdyqr20NoQqQ7jSQDgF2YyY_4MvwC2D6AfAWMCrtcJj5S-7UEadYn7fs&s=uM1vbNTejekTZereI1Gx_fzih1qMsq7oUMfBqbJJ-Ys&e= > > > > > > > > > > > > > > > > > > > > > > > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_incubator-2Dkie-2Dissues_issues_2029-23kogito-2Dapps-2Ddiagram&d=DwIFaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=Q6vLAuW9efZUIpzkybJzdGQcnEzNk9UeYj-IzYzMKJA&m=Kiy4P6Klmdyqr20NoQqQ7jSQDgF2YyY_4MvwC2D6AfAWMCrtcJj5S-7UEadYn7fs&s=s087oNTl9ggMJKqrFjl1X_Mptm1npQ5szMD8iBprzwU&e= > > > > > > > > > > > > > > > > > > > > > > > > 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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_user-2Dattachments_assets_06f8362a-2D092d-2D40bb-2D8a01-2D3560c41a4a8e&d=DwIFaQ&c=BSDicqBQBDjDI9RkVyTcHQ&r=Q6vLAuW9efZUIpzkybJzdGQcnEzNk9UeYj-IzYzMKJA&m=Kiy4P6Klmdyqr20NoQqQ7jSQDgF2YyY_4MvwC2D6AfAWMCrtcJj5S-7UEadYn7fs&s=QOr_Y2CDLZwvnTpv8I2UkCbvy8IVxYJpfwgT6IDiJIQ&e= > > > > > > > > > > > > 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] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > 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] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
