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