Well the Apache PLC4X Project would definitely welcome a soon release of 2.0.0 
as currently all modules related to SCXML have to be disabled for releases.
So I agree that it would be better to finally release a 2.0.0 and to pass a 
2.1.0 with additional stuff later on.

Chris

Am 23.04.19, 15:50 schrieb "Ate Douma" <a...@douma.nu>:

    Hi Jake,
    
    On 19/04/2019 16.15, Jacob Beard wrote:
    > Hi Ate,
    > 
    > Thanks for your reply. I think I could help with these issues, and close 
the gap for full compliance of the js language model.
    
    That would be great and definitely appreciated.
    
    But that said: I'm still worried if it actually is worth the effort.
    Because: who is looking for or (still) waiting for js language
    support in commons-scxml?
    Community wise, there have been no concrete questions or requests
    concerning the js language for many years.
    And with the Nashorn engine now deprecated, the current implementation
    is besides being incomplete, not sustainable in the long run anyway.
    Of course we could consider adding support for GraalVM instead, but is
    anyone really asking or waiting for that either?
    
    We currently have pretty solid and SCXML compliant language support with
    jexl and groovy, which might be good enough in practice for many, if not
    all, of the community.
    What I really dislike is further delaying the 2.0 release just because
    of the incomplete js language support, and with a unclear idea if it
    ever can/will be completed.
    
    Although I personally would still vote +1 to remove js language support,
    I also can agree to keep it for a while longer to allow others like you
    to chime in and try completing.
    But pending that uncertain outcome, I rather proceed with the 2.0
    release ASAP anyway, explicitly stating the js language support is not
    finished and to be considered alpha or beta.
    
    > 
    > I was wondering, did you have a timeline in mind for the 2.0 release? I 
should start to free up in June/July.
    
    I may be able to spend some cycles the coming month (May) to proceed
    with the above idea and work towards a 2.0 release, independent of the
    js language support status.
    Once we have a 2.0 release out, we can (more) easily roll out newer
    minor/patch releases thereafter for improved js language support if and
    when we get that incorporated.
    
    Regards,
    Ate
    
    > 
    > Let me know what you think. Thank you,
    > 
    > Jake
    > 
    >> On Apr 18, 2019, at 3:46 PM, Ate Douma <a...@douma.nu> wrote:
    >>
    >>
    >>
    >>> On 18/04/2019 18.00, Jacob Beard wrote:
    >>> Hi Ate,
    >>>> On Apr 18, 2019, at 11:23 AM, Ate Douma <a...@douma.nu> wrote:
    >>>>
    >>>> Only for the javascript language (using Java 8 Nashorn, now deprecated
    >>>> since Java 11...) there are still 3/188 W3C IRP tests failing.
    >>>> And those 3 test failures are really, really difficult to fix, because
    >>>> of limitations/quirks in the Nashorn engine itself.
    >>> Could you please provide more information on this? Which tests are 
failing, and what are the limitations and quirks of Nashorn that cause this?
    >>
    >> Sure.
    >>
    >> Regarding 'quirks': see issue SCXML-273 [1] which concerns the problem
    >> that the Nashorn engine by default doesn't fail on referencing a missing
    >> property. Which is tested by W3C IRP test 307.
    >>
    >> Regarding limitations: there are two W3C IRP ecma test, 557 and 561,
    >> which make use of XML DOM APIs in a condition, like:
    >>
    >>   cond="var1.getElementsByTagName('book')[0].getAttribute('title') == 
'title1'"
    >>
    >> However Nashorn doesn't provide default/native XML DOM support, and
    >> adding that would be (at least from my perspective) quite an effort, if
    >> even properly doable.
    >> That doesn't feel like worth the effort, with little added value/ROI.
    >>
    >> [1] https://issues.apache.org/jira/browse/SCXML-273
    >>
    >>> Thank you,
    >>> Jake
    >>> ---------------------------------------------------------------------
    >>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
    >>> For additional commands, e-mail: user-h...@commons.apache.org
    >>
    > 
    
    ---------------------------------------------------------------------
    To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
    For additional commands, e-mail: dev-h...@commons.apache.org
    
    

Reply via email to