Thank you for interest. Like I said this is a separate module that is easy to pick out if needed later.
1. Yes this is another way for defining and grouping rules. 2. org.kie.j2cl is actually something I need to remove. It comes from our j2cl dependencies that are mainly used by tooling. It will be replaced with pure Java approach. This is was used so that the model-to-YAML-to-model functionality could be the same and reused in the J2CL client side. 3. Right now the driver is scorecards, but this can also be used for data aggregation. In the simple cases it could be merging one or more YAML/JSON files to a new file using rule logic. This is right now on alpha stage and for that reason experimental. This does mean that in case it is not useful in future use the bar to remove it should be low. Toni On 2025/07/04 12:47:47 Gabriele Cardosi wrote: > Hi Tony, > this seems an interesting feature, indeed. > Anyway, as I mentioned in the past for other similar improvements, I think > the main concern should be the evaluation of pros/cons, since we are > already struggling to maintain the codebase as it is and this new > implementation, inevitably, would increase the surface. > First of all I'm looking at the code here [1], and I take for granted that > all that code would be incorporated inside the drools repository: please > correct me if I'm wrong. > 1. IIUC, this is first of all another way to define rules to be invoked by > the rule engine: is that true, or the execution is delegated to a > completely different engine ? > 2. I see dependencies like -> org.kie.j2cl.tools; I have no idea what's > inside, but the name suggest something on the tool/ui side (j2cl, tools) > and, if that is true, such kind of dependencies should not get in the > "backend" side > 3. What is the concrete driver for this initiative? I mean, what use > case/issue currently exists that would be solved by that implementation ? > > Beside minor technical issues or doubts, the main problem from my POV is in > the overall approach we have to our codebase after the Apache migration. > For different reasons, we have to be extremely careful about the stability > and maintenance of our projects, and indeed we should start removing > dead/unused/unmaintained code for our sake. > So, I think we should have a sort of "experimental" or similar branch > (unfortunately, "incubator" name has already been taken), so that on one > side we may promote innovation, as this proposal seems to point to, but on > the other side without increasing the burden of maintain the code with > something that is not necessary. > > > I want to enforce the point that I have nothing against the idea by itself, > but I'm only concerned about our overall context. > > Many thanks > > Best > > Gabriele > > ---- > 1 https://github.com/kubesmarts/yard > > Il giorno ven 4 lug 2025 alle ore 14:19 Toni Rikkola <rikk...@apache.org> > ha scritto: > > > Hello, > > > > Summary: > > > > When we moved to KIE, YARD was still in experimental mode. We did move > > the editors and validation tooling (in kie-tools ATM), but runtime was > > left behind. I previously proposed adding YARD in, but it was seen as a > > risk for the up coming releases. > > > > Assignee: Me, Toni Rikkola > > > > Target Release: ASAP > > > > Scope: > > > > This will go into the incubator-kie-drools repository as a separated > > unit. No dependencies to any other part of KIE will be added. > > > > Description: > > > > YARD. Yet Another Rule Definition is best explained in the README.MD > > with pictures. It is a work in progress project where the current main > > driver is the decision table feature. > > > > https://github.com/kubesmarts/yard > > > > Testing: Unit tests. Human validation is not relevant at this point > > since the project is in Alpha stage. > > > > Dependencies: Drools > > > > > > Thank you > > > > Toni Rikkola > > > > > > --------------------------------------------------------------------- > > 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
