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 > >
