Hi Alex, the main problem is that the same library/version could be defined only once in a single BOM. It may happen - and already happened to myself multiple times - that springboot and quarkus needs different versions of the same library, and the only possible solution is to manually go to downstream projects and exclude/override that version case-by-case. Besides, IMO smaller and well-focused poms are much easier to manage then aggregated ones - of course this is a personal opinion. Last, if framework-specific changes are required, having them inside kogito-runtimes avoid the hassle of a multi-repo PR, that is what happen currently (i.e. change the pom on the drools repo, go to kogito-runtimes and verify, etc etc). I hope this clarify and make sense
Il giorno mer 30 lug 2025 alle ore 15:47 Alex Porcelli <[email protected]> ha scritto: > I might be missing some context around the motivation or goal behind > the idea of creating multiple BOMs. Could you please share more > details? > > To better understand how BOMs (Bill of Materials) work in practice, I > created the following gist [1]. It demonstrates that BOMs are > essentially loosely defined collections that don't directly impact a > project's dependencies unless those dependencies are explicitly > referenced. For example, in this BOM [2], there's a dependency listed > that doesn't even exist. Yet, when a project imports this BOM [3], it > is unaffected by the missing artifact [4]. The only dependencies that > are brought into the project are those explicitly declared in its > dependencies section [5] (or those resolved transitively). > > The reason I'm asking is that having a large list of entries in a > single BOM doesn't seem to pose any functional issue for consumers—but > maintaining multiple BOMs introduces overhead and complexity. So I'm > trying to understand better what problem we're trying to solve with > this split. > > [1] - https://gist.github.com/porcelli/cda4993a168a1367285155e57968d2c7 > [2] - > https://gist.github.com/porcelli/cda4993a168a1367285155e57968d2c7#file-bom-pom-xml-L12-L14 > [3] - > https://gist.github.com/porcelli/cda4993a168a1367285155e57968d2c7#file-pom-xml-L11-L17 > [4] - > https://gist.github.com/porcelli/cda4993a168a1367285155e57968d2c7#file-clean-install-log > [5] - > https://gist.github.com/porcelli/cda4993a168a1367285155e57968d2c7#file-dependency-tree-log > > On Tue, Jul 29, 2025 at 4:54 AM Paolo Bizzarri <[email protected]> wrote: > > > > Hi, > > > > this discussion comes after the concerns expressed by Gabriele in this > > comment on this PR. > > > > > https://github.com/apache/incubator-kie-drools/pull/6352#issuecomment-2911439196 > > > > I want to address Gabriele's main points: > > > > - keep Drools as much as possible separated from frameworks like Quarkus > > and Springboot > > - provide separate BOMs for Quarkus Extension and Springboot Extension. > > > > The idea is to have three BOMs - one for simple Drools projects, one for > > projects that use Droos + Quarkus and one for projects that use Drools + > > SpringBoot. > > > > In this way if a project needs just Drools it could use only the Drools > > BOM, while a project that wants to use also Quarkus would have to use the > > Drools + Quarkus BOM. > > > > This is a breaking change however - projects that want to use Drools + > > Quarkus will have to use a different BOM. We can address this in the > > release notes. > > > > I expect the complexity of this change to be minimal, and I am going to > > take care of it. > > > > Let me know your opinion. > > > > Regards > > > > P. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
