Everything Drools runtime related should be in the Drools repo. Reason is that Drools should have a separate community release cycle. As it is, Drools could release weekly if it wanted to.
Drools is one of the bits that desperately needs community releases to stay relevant. In itself it has no sell or support value. However without wide usage. Supported by frequent releases the market of using Drools. For free as an open source project. Community use goes down. Community use goes down, committer count goes down. Community use goes down, sales go down for vendors. It is beneficial for absolutely everyone that Drools releases often. Toni On 2025/07/29 17:13:26 Paolo Bizzarri wrote: > Hi Jason, > > this is a good question. > > I would probably try to be minimalistic and use the smallest possible BOMs. > ideally if you do not need a feature you should not use the related BOMs. > > However my - limited - understanding is that Drools is somehow foundational > for other Kie projects, so I am not 100% sure of the best approach here. > > If possible, I would prefer to keep the projects/products separate, or at > least connected when strictly necessary, so that in a pure drools project I > have nothing that is related to other parts of the Kie. > > However I admit I have to do some homework if this is the discussion we > want to have - my goal was very limited and focused only to Drools. > > Regards > > P. > > > > On Tue, Jul 29, 2025 at 3:54 PM Jason Porter <jpor...@ibm.com.invalid> > wrote: > > > I was going to suggest a chain of BOMs that built on top of one another, > > but you posted before I saw the email, Paolo. > > > > I like the idea of BOMs building upon each other, but there is certainly a > > trade-off for the user: more things to maintain in the pom.xml. Granted, it > > is only two vs one so not that big of a deal, and probably nothing people > > are going to be concerned about. I wanted to make sure we thought about the > > different angles. > > > > Another question I think we need to ask ourselves is this: Is KIE a single > > project, meant to be consumed as a whole, or is it a bunch of smaller > > projects that can be used however a user wants? Of course, people are going > > to create cobbled together projects no matter what we decide to do. If KIE > > is a project itself, I think it makes sense to have a single main BOM (or > > maybe three? KIE, KIE+Quarkus, KIE+SpringBoot). What are everyone’s > > thoughts? > > > > -- > > Jason Porter > > Software Engineer > > He/Him/His > > > > IBM > > > > > > From: Paolo Bizzarri <pibi...@gmail.com> > > Date: Tuesday, July 29, 2025 at 05:45 > > To: dev@kie.apache.org <dev@kie.apache.org> > > Subject: [EXTERNAL] Re: [DISCUSSION][PROPOSAL] Creating a separated BOM > > for Quarkus and SpringBoot projects in Drools > > Hi, > > > > Tibor: not sure about the impact of having a single Kie BOM. I assume we > > will have Kie BOM <- Drools BOM <- Drools + Quarkus Extension BOM as a > > chain of dependencies. My only concern is that creating a centralized BOM > > for very different projects can cause unwanted deps and pain. But this is > > not my area of expertise, so I hope others can comment. > > > > Gabriele: I think I agree, but as above I am not sure about the > > implications. Again, not my area of expertise, so I hope others can > > comment. > > > > Thanks for comments, let's see if other devs can add their thoughts. > > > > Regards > > > > P. > > > > On Tue, Jul 29, 2025 at 11:28 AM Gabriele Cardosi < > > gabriele.card...@gmail.com> wrote: > > > > > Hi Tibor, Paolo, > > > my personal view is that the quarkus/springboot boms should be placed > > > inside kogito-runtimes repository itself, and everything quarkus-related > > > should be moved from drools-repo to kogito-runtimes. > > > One of the goals IMO is to completely "clean-up" drools repository from > > any > > > framework-related dependency, and move the framework integration inside > > > kogito-runtimes. > > > Does this make sense ? > > > > > > Il giorno mar 29 lug 2025 alle ore 11:06 Tibor Zimányi < > > > tzima...@apache.org> > > > ha scritto: > > > > > > > Hi Paolo, > > > > > > > > thank you for this initiative. It is really needed, however I think it > > > > needs to be done on the whole KIE level, not just Drools level. The > > same > > > > situation is in kogito-runtimes repository. Therefore I think we need a > > > > global KIE bom and then global Quarkus bom and global Spring Boot bom. > > > > > > > > What do you think, please? > > > > > > > > Best regards, > > > > Tibor > > > > > > > > > > > > Dňa ut 29. 7. 2025, 10:54 Paolo Bizzarri <pibi...@gmail.com> > > napísal(a): > > > > > > > > > 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
