Gabriele, Could you create a similar example as I did, so you illustrate/reproduce the issue? Assuming we also agree that BOM's should limit itself to just cover our own artifacts (and not having any external library directly referenced).
- Alex On Wed, Jul 30, 2025 at 9:54 AM Gabriele Cardosi <gabriele.card...@gmail.com> wrote: > > 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 <a...@porcelli.me> > 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 <pibi...@gmail.com> 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: dev-unsubscr...@kie.apache.org > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org For additional commands, e-mail: dev-h...@kie.apache.org
