Toni, I feel a sense of urgency in your messages, and I think I understand where you’re coming from. Instead of hinting on “Drools should be separate” (which I guess is mainly motivated by the fact that our release cycle is slow), do you mind starting a separate thread with more details on your concerns, so we can all discuss how to make our releases faster?
We just did 10.1.0 a couple weeks ago, all the knowledge is fresh in Alex’s and Eduardo’s minds about our pipelines and we have a comprehensive document with all the steps necessary to perform a release. There is a foundation on which to improve, and I guess a lot of motivation to simplify and make everything leaner. Meanwhile, in this thread, I guess we could go back to the focus of BOM structure and dependency management if that’s okay with you all. Regards, Tiago Bento On Wed, Jul 30, 2025 at 06:54 Gabriele Cardosi <gabriele.card...@gmail.com> wrote: > Hi Tony, > thanks for clarification. > I agree on the content itself, of course. > Just a bit of clarification from my pov. > About naming - keep using "Drools" in this interchangeable way is confusing > - and propagate the confusion inside the technical discussions. > What you are talking about is the RULE engine - or "Rules", IINW, but the > refactoring we are discussing here involves ALL the engines > (DRL/DMN/PMML/BPMN) built around the Drools ecosystem. So, the discussion > has to be on a by-repo POV, not by engine. > Last, I thought it was an APACHE requirement to have all the "KIE" codebase > in sync, but I could be wrong, of course. > > M2C > > Best > > > > Il giorno mer 30 lug 2025 alle ore 12:21 Toni Rikkola <rikk...@apache.org> > ha scritto: > > > The Drools I am referring to is just the runtime that are needed to run > > DRL. Users are not using tooling for DRL, because there is none. For > > this reason, the Drools releases do not benefit from the tooling > > repositories. And for the rest of the KIE repositories/projects Drools > > is just a dependency, it can have a different version number. The > > releases can be synced. > > > > The problems Drools now has: > > > > 1. For example YARD has to come into KIE ( into Drools ) due to legal > > reasons. This means YARD shares the KIE release cycle now. The project > > depending on it is open source and due to the experimental nature of > > YARD ( syntax changes often ) it is now a hostage for the slow release > > cycle. > > > > 2. I have code around Drools and AI under progress. This space changes > > weekly. Making a release every 6 months is too slow. It has to live > > outside of KIE, even when it would benefit KIE. > > > > 3. Every new Drools feature has always benefited from early adoption of > > community users. Now the early adoption is every 6 months or more. Who > > would want to build on an experimental feature when you get one bug fix > > in 6 months? Then you run into a new one and OK now it has been a year. > > > > 4. Any new innovation or upcoming committers coming up suffer from #1 > > and #2. And due to that bigger code donations are blocked. > > > > I understand the points you are making, but for Drools users none of > > those matter. For the majority of them nothing else we have matters. > > Also this separate release is something for the future. Just brought > > this up since the original subject is related. Maybe more people get > > suddenly invested in maturing the project and this problem goes away. > > Who knows. Right now 3 of those few individuals working actively towards > > maturing come from the Drools team, so it is safe to say Drools guys are > > not giving up on KIE. > > > > All the opinions are my own. > > > > Toni > > > > On 30/07/2025 10.48, Gabriele Cardosi wrote: > > > Hi Tony, > > > I think the question here is more technical, i.e. how to structure and > > > where to put the poms/boms to > > > 1. centralize dependencies > > > 2. avoid overlapping/misconfiguration > > > 3. simplify management/updates > > > > > > IMO, given the current situation, repo should reflect the architectural > > > layers as much as possible, with Drools being the core library, > > > kogito-runtimes framework, etc etc. > > > It is not 100% that way, of course. > > > And, to be more community-friendly, I think we should start to use > > > consistent naming: what is the "Drools" you are referring to ? > > > The "Drools" repository ? > > > Or, everything that is related and dependent on the code that is hosted > > > inside the drools repository (i.e. all our "KIE" ecosystem) ? > > > In the former case, I thought that we could not split the release > cycle, > > > being KIE one single "project" - please correct me if I'm wrong. > > > In the latter case, it is not very clear what you mean with "Everything > > > Drools runtime related should be in the Drools repo." > > > > > > Anyway, again, the topic here is pretty simple and limited: create > three > > > boms for each different use case: plain java/spring-boot > > > integration/quarkus integration. > > > > > > Does this make sense ? > > > > > > Il giorno mer 30 lug 2025 alle ore 09:20 Toni Rikkola < > > rikk...@apache.org> > > > ha scritto: > > > > > >> 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 > > >> > > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > >
