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]
