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 > > > > > > > > >
