Hi Tony, many thanks for your answers, make sense! The only thing probably I've not been very clear about is the "driver" or business value, or whatever.
I understand that currently the implementation is targeting scorecard, but my question was about the "need" of this other implementation, since, IINW, we already have a couple of them, or more, around (I may be wrong on that, of course). Am I clear ? Does this make sense ? And, my personal POV, I would prefer to not include something that, eventually, would need to be removed, since, as we all know, removing stuff is much harder than introducing them, for different reasons.... Il giorno ven 4 lug 2025 alle ore 15:19 Toni Rikkola <rikk...@apache.org> ha scritto: > 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 > >
