Docs are publishing now for 3.5.0 after the revert: https://tinkerpop.apache.org/docs/3.5.0-SNAPSHOT/reference/
On Fri, Feb 26, 2021 at 8:17 PM Stephen Mallette <[email protected]> wrote: > I've reverted to Groovy 2.5.x and the 3.0 issue is reopened: > > https://issues.apache.org/jira/browse/TINKERPOP-2373 > > We're back to being fast on master. Going to generate docs for the first > time in months. Hopefully it won't be too big a mess. I will post back here > when I've got a new 3.5.0-SNAPSHOT published. > > On Fri, Feb 19, 2021 at 7:06 PM Josh Perryman <[email protected]> > wrote: > >> 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 >> > >> >
