Toni, Could you confirm what’s the JShell license?
On Wed, Mar 6, 2024 at 6:18 AM Toni Rikkola <rikk...@apache.org> wrote: > #1 Yep > > #2 Dependencies are: > Drools - Good old Drools we already have > org.treblereel.gwt.yaml.mapper - Under Apache 2.0 and under this community > umbrella and already used by kogito-runtimes editors. > jshell - From Oracle, a completely new dependency introduction > > Alternatives, or options that the user can select, for jshell are likely > FEEL and MVEL, both already in use by the community. This depends on the > direction we want to take this. > > #3+4 > This one is a tricky one to answer. Right now the features include > Decision Tables and Literal Expressions, but depending on the rising needs > and community approval, new features would be added by demand and by vote. > If we feel voting is necessary. > > Current driver is Red Hat's need to have simpler method for writing > Decision Logic. Once YaRD is put into use, then there are the same > requirements to maintain and support it as there is for the XLS decision > tables. Documentation, as I understand, should follow with any commit that > adds a new feature into the code base. If this is not the case, then we > might have to have a proposal about that :-) > > The implementation itself is a YAML interface to write Drools code. Giving > easier, more manageable ( but also more liming ) methods for Logic > authoring. One big driver is the ability to write Decision Tables with just > text and the benefits of Decision Tables are readability and indebt > validation ( rule overlaps, missing logic gaps and so on ). > > Even when YaRD has a specific name, on a technical level it is far closer > to the XLS Decision Tables than it is to DMN. Not saying it can not grow to > be as much as DMN, but there is only so much one file can handle. However > it does not make sense to call it YAML Decision tables, since it is a bit > more and has the potential to go further, it is and will be as the name > says: Yet Another Rule Definition. > > Toni > > On 2024/03/05 13:11:58 Gabriele Cardosi wrote: > > Hi Toni, > > to recap, it seems there are the following points of discussion (I add a > > couple) > > > > 1. timing (i.e. not before the 10.0 release, and I think we all agree > > on that) > > 2. transitory dependencies > > 3. long-term maintenance plan > > 4. community contribution to it (e.g. there is a new DRL refactoring > > initiative, and the guys after it are dedicating time and effort to > also > > document, explain, and simplify the code to facilitate external > > contribution) > > > > > > > > Il giorno mar 5 mar 2024 alle ore 13:24 Toni Rikkola <rikk...@apache.org > > > > ha scritto: > > > > > Sure I can start a vote once the 10.0.0 is done. > > > > > > I will introduce the dependencies in that vote. > > > > > > Toni > > > > > > On 2024/03/05 04:31:42 Jan Šťastný wrote: > > > > Hello Toni and others, > > > > I'd just add to this that we should also evaluate what 3rd party > > > libraries > > > > we're bringing in with this addition. If they're allowed in ASF and > if > > > they > > > > are well maintained and addressed for vulnerabilities. (Parsing > libraries > > > > seems to be prone to these issues more than others.) > > > > > > > > So I was wondering if such an addition (if/when it happens) would be > run > > > > through voting where we could safe-check the concerns I stated above, > > > > rather than a PR where it's sufficient to get 2 approving reviews > from > > > > committers. > > > > > > > > Regards > > > > Jan > > > > > > > > Dne po 4. 3. 2024 19:40 uživatel Toni Rikkola <rikk...@apache.org> > > > napsal: > > > > > > > > > Sure. I am working on this alone for now, so a reasonable delay is > not > > > an > > > > > issue. > > > > > > > > > > Tonino > > > > > > > > > > On 2024/03/04 15:26:01 Alex Porcelli wrote: > > > > > > Toni, > > > > > > > > > > > > Although you mentioned that it's quite isolated, I feel more > > > > > > comfortable if we could delay to introduce it to the codebase > after > > > > > > the 10.0.0 release - in the meantime maybe use a feature branch > > > > > > directly in the Apache repository. > > > > > > > > > > > > On Mon, Mar 4, 2024 at 10:15 AM Toni Rikkola <rikk...@apache.org > > > > > wrote: > > > > > > > > > > > > > > Future goals can include having YaRD next to SonataFlow. > Allowing > > > easy > > > > > access to Decision Tables and other Decision logic that is not > easy to > > > > > implement with a flow structure and of course the other way around. > > > > > > > > > > > > > > However there are also other targets. One method is to use the > YaRD > > > > > files as scorecards. Based on the inputs the end result gives a % > of > > > > > success. > > > > > > > > > > > > > > YaRD can also be used to aggregate several REST calls into a > one > > > more > > > > > preferable format. > > > > > > > > > > > > > > Toni > > > > > > > > > > > > > > On 2024/03/04 14:27:07 Yeser Amer wrote: > > > > > > > > Hi Tonino! > > > > > > > > > > > > > > > > Thanks for sharing a brief description of YaRD here. > > > > > > > > I agree with you that having the editor in kie-tools > (apache) and > > > > > the engine in another area (kie?) is not ideal. > > > > > > > > > > > > > > > > Can I ask where the code is currently located? > > > > > > > > Since you said the feature is "experimental", can I ask what > the > > > > > plans are for YaRD? > > > > > > > > I think clarifying this point can help us make the best > decision. > > > > > > > > > > > > > > > > > > > > > > > > On 2024/03/04 13:53:07 Alex Porcelli wrote: > > > > > > > > > Toni, > > > > > > > > > > > > > > > > > > As in previous discussion related to the new Drools > parser, my > > > > > concern > > > > > > > > > is how much this might affect the 10.0.0 release. > > > > > > > > > > > > > > > > > > I personally am not a big fan of YAML, in a recent demo I > got > > > in > > > > > > > > > trouble because of 2 spaces :D - but I understand that this > > > might > > > > > look > > > > > > > > > appealing to k8s audience :) > > > > > > > > > > > > > > > > > > On Mon, Mar 4, 2024 at 8:23 AM Toni Rikkola < > t...@rikkola.net> > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > > > I am proposing we add YaRD into the kie-drools > repository. > > > YaRD > > > > > is used > > > > > > > > > > to describe Decisions, Rules and Declarative logic in the > > > YAML > > > > > format. > > > > > > > > > > At the current state it supports Decision Tables and > Literal > > > > > > > > > > Expressions. > > > > > > > > > > > > > > > > > > > > Example of a Decision Table is in attached file > > > > > > > > > > "yard-dtable-example.txt". ( In .txt for easier viewing. > ) > > > > > > > > > > A more complex example is in attached "costs.txt". > > > > > > > > > > > > > > > > > > > > The YAML structure and the used scripting language is not > > > set in > > > > > stone > > > > > > > > > > and the feature at the moment is experimental. > > > > > > > > > > > > > > > > > > > > Under the YAML cover it runs Drools, in more detail the > > > Drools > > > > > Rule > > > > > > > > > > Units DSL. > > > > > > > > > > > > > > > > > > > > Due to the move to Apache we are in a weird situation > where > > > we > > > > > already > > > > > > > > > > have an editor for YaRD in kie-tools without a backend. > The > > > > > existing > > > > > > > > > > editor has a simple autocomplete with support for > Validation > > > > > that finds > > > > > > > > > > redundancy and subsumption from the Decision Tables. To > > > follow > > > > > the > > > > > > > > > > Apache community rules and to show visibility I am now > > > asking for > > > > > > > > > > approval to add the backend in. > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > 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 > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > 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 > >
