Hi, I agree to slim down to have only one keyword for this. However I will play a bit of devil's advocate here. I was not back then involved when the term "agenda-group" was introduced, however my personal feeling is that the term "rule flow" is actually much more widely known with business automation users. So I personally think that it may be better to actually get rid of agenda-group and use only ruleflow-group. However no strict opinion on this. I am fine if we decide either way.
What do you think, please? Best regards, Tibor Dňa št 23. 1. 2025, 11:01 Toshiya Kobayashi <toshiyakobaya...@gmail.com> napísal(a): > Hi all, > > Currently I'm working on this slim down. > > Mario suggested one more slim down -- "ruleflow-group". > ---- > ruleflow-group capability is actually the same as agenda-group, so it > doesn’t make sense to keep both attributes in DRL syntax. > > It doesn't mean we drop the ruleflow feature. Not directly related to the > current dev ML discussion "ruleflow kjar use case". Users would just need > to replace "ruleflow-group" with "agenda-group" in drl. > > This change only for drl parser. Java method deprecate/drop can be planned > later. > ---- > > Feel free to share your thoughts. > > Thanks, > Toshiya > > On Mon, Dec 16, 2024 at 8:03 PM Alex Porcelli <a...@porcelli.me> wrote: > > > Thank you, Toshiya! > > > > > > On Mon, Dec 16, 2024 at 1:32 AM Toshiya Kobayashi < > > toshiyakobaya...@gmail.com> wrote: > > > > > Hi, > > > > > > I haven't yet finished the slim down / warnings etc. I'll do and keep > you > > > updated on this thread. > > > > > > Thanks, > > > Toshiya > > > > > > > > > On Sun, Dec 15, 2024 at 7:07 AM Alex Porcelli <a...@porcelli.me> > wrote: > > > > > > > (bumping this thread) > > > > > > > > Toshiya, > > > > > > > > As the current parsers don't exactly match the proposal I sent.. > Could > > > > you adjust it and share here what it would look like? > > > > > > > > Thank you in advance! > > > > > > > > On Tue, Nov 19, 2024 at 10:52 PM Toshiya Kobayashi > > > > <toshiyakobaya...@gmail.com> wrote: > > > > > > > > > > > Ohh and I also found the change-set.xsd... maybe add it as part > of > > > this > > > > > cleanup? > > > > > > > > > > Thanks again. Yes, it should be cleaned up. > > > > > > > > > > Filed https://github.com/apache/incubator-kie-drools/issues/6163 > > > > > > > > > > Toshiya > > > > > > > > > > On Tue, Nov 19, 2024 at 11:16 PM Alex Porcelli <a...@porcelli.me> > > > wrote: > > > > > > > > > > > Ohh and I also found the change-set.xsd... maybe add it as part > of > > > this > > > > > > cleanup? > > > > > > > > > > > > On Tue, Nov 19, 2024 at 4:16 AM Toshiya Kobayashi > > > > > > <toshiyakobaya...@gmail.com> wrote: > > > > > > > > > > > > > > Thank you for the notice. > > > > > > > > > > > > > > > ./drools-compiler/src/main/resources/META-INF/drools-4.0.xsd > > > > > > > > ./drools-compiler/src/main/resources/META-INF/drools-5.2.xsd > > > > > > > > > > > > > > This is for rules in xml format. The feature is very old and > not > > > > > > > documented. I think we can deprecate and drop. > > > > > > > > > > > > > > Filed > https://github.com/apache/incubator-kie-drools/issues/6159 > > > > > > > > > > > > > > > > > > > > ./drools-compiler/src/main/resources/META-INF/drools-processes-5.0.xsd > > > > > > > > > > > > > > This is for .rf file (rule flow). It's no longer supported > since > > > > drools > > > > > > 8. > > > > > > > We should clean-up it. > > > > > > > > > > > > > > Filed > https://github.com/apache/incubator-kie-drools/issues/6160 > > > > > > > > > > > > > > Thanks, > > > > > > > Toshiya > > > > > > > > > > > > > > > > > > > > > On Tue, Nov 19, 2024 at 10:16 AM Alex Porcelli < > a...@porcelli.me > > > > > > > wrote: > > > > > > > > > > > > > > > Ohh what the following XSD formats? They might not be > directly > > > > related > > > > > > > > to parser, but it's in the same problem domain I think. > > > > > > > > > > > > > > > > ./drools-compiler/src/main/resources/META-INF/drools-4.0.xsd > > > > > > > > ./drools-compiler/src/main/resources/META-INF/drools-5.2.xsd > > > > > > > > > > > > > ./drools-compiler/src/main/resources/META-INF/drools-processes-5.0.xsd > > > > > > > > > > > > > > > > On Mon, Nov 18, 2024 at 5:35 AM Alex Porcelli < > > a...@porcelli.me> > > > > > > wrote: > > > > > > > > > > > > > > > > > > Thank you for the clarification and the confirmation that > the > > > > > > > > > DRL6_STRICT enforces the `more correct` form. > > > > > > > > > > > > > > > > > > I wonder if in the effort to remove ambiguities in the > DRL10 > > > > parser, > > > > > > > > > is the DRL6_STRICT incorporated or the DRL6 mode (not > strict) > > > > used? > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Nov 18, 2024 at 2:40 AM Toshiya Kobayashi > > > > > > > > > <toshiyakobaya...@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > Could you clarify what's exactly the difference between > > > DRL6 > > > > > > Strict > > > > > > > > > > > and DRL parsers? Probably the wording STRICT is > confusing > > > > me, as > > > > > > > > > > > usually this term is used to enforce best practices. > > > > > > > > > > > > > > > > > > > > DRL6_STRICT means "supports strictly typed annotation". > > > > > > > > > > > > > > > > > > > > DRL6_STRICT parser requires FQCN annotations which need > to > > be > > > > > > resolved > > > > > > > > by > > > > > > > > > > classloader while DRL6 parser accepts String based > > annotation > > > > > > names. > > > > > > > > Also > > > > > > > > > > the annotation position is different (In DRL6_STRICT, > > > > annotation is > > > > > > > > placed > > > > > > > > > > before its target declaration. In DRL6, annotation is > > placed > > > > after > > > > > > its > > > > > > > > > > target declaration). There is no difference other than > > > > annotation. > > > > > > > > > > > > > > > > > > > > For example) > > > > > > > > > > > > > > > > > > > > DRL6_STRICT: > > > > > > > > > > > > > > > > > > > > import org.example.Xyz; > > > > > > > > > > > > > > > > > > > > @Xyz rule R1 > > > > > > > > > > when > > > > > > > > > > then > > > > > > > > > > end > > > > > > > > > > > > > > > > > > > > DRL6: > > > > > > > > > > > > > > > > > > > > // no need of import for Xyz > > > > > > > > > > > > > > > > > > > > rule R1 @Xyz > > > > > > > > > > when > > > > > > > > > > then > > > > > > > > > > end > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Toshiya > > > > > > > > > > > > > > > > > > > > On Sun, Nov 17, 2024 at 8:31 PM Alex Porcelli < > > > > a...@porcelli.me> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Thank you for the clarifications, Thoshiya. > > > > > > > > > > > > > > > > > > > > > > Could you clarify what's exactly the difference between > > > DRL6 > > > > > > Strict > > > > > > > > > > > and DRL parsers? Probably the wording STRICT is > confusing > > > > me, as > > > > > > > > > > > usually this term is used to enforce best practices. > > > > > > > > > > > > > > > > > > > > > > On Tue, Nov 12, 2024 at 10:28 PM Toshiya Kobayashi > > > > > > > > > > > <toshiyakobaya...@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > Thank you very much for the reply, Alex. > > > > > > > > > > > > > > > > > > > > > > > > I totally agree with user communication and gradual > > > > approach. > > > > > > > > > > > > > > > > > > > > > > > > Btw, "Strict mode" and "legacy mode" likely don't fit > > > well > > > > > > with the > > > > > > > > > > > parser > > > > > > > > > > > > architecture. > > > > > > > > > > > > > > > > > > > > > > > > One parser implementation is tied to one > > > > LanguageLevelOption. > > > > > > > > > > > > > > > > > > > > > > > > In the current codebase, > > > > > > > > > > > > > > > > > > > > > > > > The new parser -> DRL6 > > > > > > > > > > > > The old DRL6 parser -> DRL6 > > > > > > > > > > > > The old DRL6_STRICT parser -> DRL6_STRICT > > > > > > > > > > > > The old DRL5 parser -> DRL5 > > > > > > > > > > > > > > > > > > > > > > > > (Sorry, I haven't mentioned the old DRL6_STRICT/DRL5 > > > > parsers > > > > > > > > before, but > > > > > > > > > > > > they exist) > > > > > > > > > > > > > > > > > > > > > > > > But the proposal is > > > > > > > > > > > > > > > > > > > > > > > > The new parser -> DRL10 > > > > > > > > > > > > The old DRL6 parser -> DRL6 > > > > > > > > > > > > The old DRL6_STRICT parser -> DRL6_STRICT > > > > > > > > > > > > The old DRL5 parser -> DRL5 > > > > > > > > > > > > > > > > > > > > > > > > and considering the migration plan. > > > > > > > > > > > > > > > > > > > > > > > > You seem to assume that the new parser can handle all > > > DRL5, > > > > > > DRL6 > > > > > > > > and > > > > > > > > > > > DRL10. > > > > > > > > > > > > But it can't. > > > > > > > > > > > > > > > > > > > > > > > > The new parser (DRL10) is itself "strict mode" and > the > > > old > > > > DRL6 > > > > > > > > parser is > > > > > > > > > > > > itself "legacy mode". Users can choose any parser as > > long > > > > as > > > > > > they > > > > > > > > exist. > > > > > > > > > > > > > > > > > > > > > > > > So the point is how we will provide warnings. > > > > > > > > > > > > > > > > > > > > > > > > 1. Introduce the new parser(DRL10), but make it > > optional > > > > (not > > > > > > > > enabled by > > > > > > > > > > > > default). > > > > > > > > > > > > 2. Raise warnings when the syntax to be dropped are > > used > > > > **in > > > > > > the > > > > > > > > old > > > > > > > > > > > DRL6 > > > > > > > > > > > > parser**, saying these syntax are deprecated. > > > > > > > > > > > > Raise warnings when DRL5 and DRL6_STRICT are used, > > > > saying > > > > > > these > > > > > > > > > > > language > > > > > > > > > > > > levels are deprecated. > > > > > > > > > > > > <six months later> > > > > > > > > > > > > 3. Raise warnings when DRL6 is used, saying DRL10 > will > > be > > > > the > > > > > > > > default in > > > > > > > > > > > > the future > > > > > > > > > > > > <six months later> > > > > > > > > > > > > 4. Make the new parser(DRL10) default > > > > > > > > > > > > <xxx months later> > > > > > > > > > > > > 5. In the next major release (version 11), drop the > old > > > > DRL5 > > > > > > and > > > > > > > > > > > > DRL6_STRICT parsers > > > > > > > > > > > > <xxx months later> > > > > > > > > > > > > 6. In the major release after that (version 12), drop > > the > > > > old > > > > > > DRL6 > > > > > > > > > > > parser, > > > > > > > > > > > > it means the deprecated syntax cannot be used at this > > > > point. > > > > > > > > > > > > > > > > > > > > > > > > How does it sound? > > > > > > > > > > > > > > > > > > > > > > > > Additional points: > > > > > > > > > > > > Until step 3, probably most community users are not > > aware > > > > of > > > > > > the > > > > > > > > new > > > > > > > > > > > > parser(DRL10) even if documented. We may promote it > in > > > the > > > > > > > > community and > > > > > > > > > > > > collect feedback. > > > > > > > > > > > > > > > > > > > > > > > > > Additionally, I think eval should be handled > > > > differently. It > > > > > > > > needs its > > > > > > > > > > > > > own thread and likely more discussion, as well as a > > > > clear and > > > > > > > > careful > > > > > > > > > > > > > communication plan for its deprecation. > > > > > > > > > > > > > > > > > > > > > > > > Agreed. > > > > > > > > > > > > > > > > > > > > > > > > > Finally, I’d recommend including a migration tool > as > > > > part of > > > > > > > > this plan > > > > > > > > > > > > > to help users transition more smoothly. > > > > > > > > > > > > > > > > > > > > > > > > Agreed. > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > Toshiya > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Nov 12, 2024 at 9:41 PM Alex Porcelli < > > > > > > a...@porcelli.me> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Thank you, Toshyia for the proposal! > > > > > > > > > > > > > > > > > > > > > > > > > > I have a concern about making these changes without > > the > > > > > > proper > > > > > > > > > > > > > communication channels in place. We agreed a while > > back > > > > to > > > > > > focus > > > > > > > > on > > > > > > > > > > > > > the release first and address communication > > afterward. > > > > > > > > > > > > > > > > > > > > > > > > > > Once the communication plan is sorted out, I > suggest > > a > > > > more > > > > > > > > gradual > > > > > > > > > > > > > approach to introduce the new parser: > > > > > > > > > > > > > > > > > > > > > > > > > > - First, introduce the new parser, but make it > > optional > > > > (not > > > > > > > > enabled > > > > > > > > > > > > > by default). Start by showing warnings for any > syntax > > > > that > > > > > > will > > > > > > > > be > > > > > > > > > > > > > removed, including v5 syntax. > > > > > > > > > > > > > - About six months later, add warnings for users > not > > > yet > > > > > > using > > > > > > > > the new > > > > > > > > > > > > > parser, and introduce a "strict mode" (which won’t > be > > > > > > enabled by > > > > > > > > > > > > > default). > > > > > > > > > > > > > - Another six months later, set the new parser as > the > > > > > > default. > > > > > > > > > > > > > - Enable strict mode by default. > > > > > > > > > > > > > - In the next major release (version 11), adopt the > > new > > > > > > parser > > > > > > > > as the > > > > > > > > > > > > > default and remove old syntaxes. Add a "legacy > mode" > > to > > > > > > support > > > > > > > > older > > > > > > > > > > > > > syntaxes, with warnings for their use, and drop v5 > > > > syntax. > > > > > > > > > > > > > - In the major release after that (version 12), > > > > completely > > > > > > > > remove all > > > > > > > > > > > > > old syntaxes. > > > > > > > > > > > > > > > > > > > > > > > > > > Additionally, I think eval should be handled > > > > differently. It > > > > > > > > needs its > > > > > > > > > > > > > own thread and likely more discussion, as well as a > > > > clear and > > > > > > > > careful > > > > > > > > > > > > > communication plan for its deprecation. > > > > > > > > > > > > > > > > > > > > > > > > > > Finally, I’d recommend including a migration tool > as > > > > part of > > > > > > > > this plan > > > > > > > > > > > > > to help users transition more smoothly. > > > > > > > > > > > > > > > > > > > > > > > > > > Alex > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Nov 12, 2024 at 12:26 AM Toshiya Kobayashi > > > > > > > > > > > > > <toshiyakobaya...@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > > > > > > > > > > > We have merged a new Antlr4 based DRL parser in > the > > > > drools > > > > > > main > > > > > > > > > > > branch. > > > > > > > > > > > > > > It's not enabled by default, so it doesn't affect > > > users > > > > > > now. > > > > > > > > > > > > > > > > > > > > > > > > > > > > The new parser has been focused on backward > > > > compatibility > > > > > > and > > > > > > > > > > > existing > > > > > > > > > > > > > unit > > > > > > > > > > > > > > tests are all green with it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > However, at this point, we can take an > opportunity > > to > > > > "slim > > > > > > > > down DRL > > > > > > > > > > > > > > syntax" in order to improve the future > > > maintainability > > > > of > > > > > > > > drools. > > > > > > > > > > > > > > > > > > > > > > > > > > > > PROPOSAL is > > > > > > > > > > > > > > > > > > > > > > > > > > > > - Drop or modify some DRL syntax, which cause > > > > maintenance > > > > > > cost > > > > > > > > and/or > > > > > > > > > > > > > > ambiguity and/or are less useful. > > > > > > > > > > > > > > - Introduce LanguageLevelOption.DRL10 for the new > > > > syntax. > > > > > > > > Enabled > > > > > > > > > > > when > > > > > > > > > > > > > > configured. It is handled by the new parser. > > > > > > > > > > > > > > - Announce "deprecate" for the dropped syntax, so > > > that > > > > > > users > > > > > > > > can > > > > > > > > > > > migrate > > > > > > > > > > > > > to > > > > > > > > > > > > > > DRL10. > > > > > > > > > > > > > > - At some point in the future, make > > > > > > LanguageLevelOption.DRL10 > > > > > > > > > > > default. > > > > > > > > > > > > > > (Still keep DRL6 and the old parser as a > transition > > > > period) > > > > > > > > > > > > > > - When we consider the new parser is mature, we > > will > > > > remove > > > > > > > > DRL6 and > > > > > > > > > > > the > > > > > > > > > > > > > > old parser > > > > > > > > > > > > > > > > > > > > > > > > > > > > Further details and candidates syntax to drop are > > > > written > > > > > > in > > > > > > > > this > > > > > > > > > > > docs. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://docs.google.com/document/d/1Ibmj-koAMbeaungHuFeQtw2zD03YJcNJkJ-kdN8ugks/edit?usp=sharing > > > > > > > > > > > > > > > > > > > > > > > > > > > > Feel free to add comments on the docs. Discussing > > > this > > > > on > > > > > > the > > > > > > > > thread > > > > > > > > > > > is > > > > > > > > > > > > > > also great. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > Toshiya > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > > > 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 > > > > > > > > > > > > > >
