As an interested observer, I think your concerns regarding Groovy are valid. All of your considerations look entirely reasonable. Perhaps move it to "risk" as suggested, and note it in the next board report. Maybe the Apache board has some pull in this situation?
Reducing dependency on Groovy doesn't add a whole lot of value, but not being able to build the documentation is a definite problem. It's a shame. I rather like Groovy, though my actual professional use of it has been limited. -Josh On Fri, Feb 19, 2021 at 6:17 AM Stephen Mallette <[email protected]> wrote: > Given the performance problems with Groovy 3.0 that I've detailed in this > thread: > > > https://lists.apache.org/thread.html/rbd7b09e53f7a0e421057192ed564907755252b8bd43085ecb16f98e4%40%3Cdev.tinkerpop.apache.org%3E > > and further documented in this issue: > > https://issues.apache.org/jira/browse/TINKERPOP-2526 > > and compounded by what I can only describe as unprecedented disinterest in > the problem by the Groovy Community, I think it wise that we revert 3.0 and > go back to 2.x. Thankfully, I think it was just this commit: > > > https://github.com/apache/tinkerpop/commit/cc3c5cb83e253b9949076628a7cfaade7f86f40e > > I will then reopen the Groovy 3.0 issue: > > https://issues.apache.org/jira/browse/TINKERPOP-2373 > > and link it to the performance blocker with TINKERPOP-2526. > > If there are no objections in the next 72 hours, I'll assume lazy consensus > and push on in this direction. > > I'm a bit shocked by the lack of feedback I've gotten on this issue from > Groovy to be honest. Just silence. It's understandable in that it is > perhaps a difficult/complex problem to get into but it's been months now > and without at least some direction and communication with Groovy project > members I could spend weeks developing a fix that may not even be > acceptable to be integrated into their code base. > > I don't want to read too much into this situation but it highlights our > continued dependence on Groovy despite our attempts to get better > separation as we went to TinkerPop 3. I'm starting to feel concerned that > this dependence is shifting further to "risk". I don't think we need to > make any immediate decisions, but with the expected move to processing > Gremlin with antlr (i.e. gremlin-script)[1] it might be time to try to cut > the cord further. Perhaps we switch to JShell for the Gremlin Console or > develop our own repl around gremlin-script?? Maybe we also deprecate Groovy > as a ScriptEngine in Gremlin Server and only host gremlin-script?? I > suppose that all of this is ideas for a different thread and for a > different day. > > [1] > > https://lists.apache.org/thread.html/rc9288877898d583b3307eebf09949d5887081da38186dd82e59077ae%40%3Cdev.tinkerpop.apache.org%3E >
