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
