Hello Team, I am writing to let you know that like many others I greatly value the work being done on commons-scxml and look forward to release 2.0.
Please keep up the good work. Regards, Diptendu Dutta On Thu, Apr 18, 2019 at 9:04 PM Ate Douma <a...@douma.nu> wrote: > Hi developers/community, > > I've received an out-of-band request about the current status of > commons-scxml-2.0 and its release schedule. > > As there might be more (hopefully at least a few) people interested in > this, and I don't like answering out-of-band questions, I'm giving > a heads-up here for the whole community. > > To be absolutely clear upfront: I've dropped the ball on this (again) > since my last burst of changes early 2018. > I simply didn't, and still don't, have the cycles and priority to work > on this beyond maybe minimally answering a few questions now and then. > > Now, there have been only very few questions in the last several years, > and luckily Woonsan (who is a remote colleague of mine in our d2d job) > stepped in to help with those as well. > So practically, there hasn't been much demand or pressure to wrap-up > the work and finish the 2.0 release. > And neither from my d2d job (we're still happily using the 2.0-M1 > release without problems so far). > > But technically, the current master branch towards the 2.0 release *is* > practically done and ready to be tagged and released. If/when a few > remaining cleanup and polishing tasks are completed... > > The current master branch *is* already fully compliant with the W3C > SCXML 1.0 specification, including passing all the W3C (IRP) tests for > it. At least, when using the jexl or groovy script languages. > And the Common SCXML 2.0 engine IMO is pretty cool and convenient to > use, for those who like/need a formalized statemachine engine. > > 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. > So that is where I got 'stuck'. > I honestly lost interest and desire to try fix this, given that Nashorn > now is deprecated in Java 11 anyway, I don't think anyone is actually > using/waiting for the javascript language support to begin with, and so > I rather just/simply rip out the whole javascript language support and > be done with it. > > And then, there is the remaining work to: > a) Fix/remove/replace existing documentation, which is still mostly > based upon the last 0.9 release from more than a decade ago. > To do this properly is/would be a major effort in itself, as the > commons-scxml-2.0 API is really, really different now. > b) Fix/configure the site generation itself (I'm actually clueless) > c) Check/adjust current checkstyle and other build/release reports to be > more in line with the common practices for Apache Commons projects? > > For task a) I assume I'd have to take first responsibility, > possible/hopefully with some help from Woonsan, because 80+% of the code > and API changes were made by me, the rest by Woonsan. > However I honestly don't have the cycles to do this properly right now. > But if it is acceptable to only do the bare minimum, and at least remove > the out-of-date examples and just have a basic/minimal 'getting > started' page, I could pull that off in a few weeks time. > > For task b) I assume other devs may be able to help out a bit: I just > needs some explanation and clarification how this (now) is supposed to > work. > > Lastly, for task c) I don't know what the current/common policy is or > should be: the only thing I realized is that the current reporting > configuration is extremely old (10+ years) and might need adjusting. > I guess this is also something other Commons devs might be able to > explain or even help out with? > > Looking forward to further input, and hopefully some offered help, > because I really would like to wrap this up, sometime soon. > > Regards, > Ate > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > >
