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]
