Sorry - those imports are really mysterious to me. I dug through a fair bit of groovy code trying to figure out what the rules were for that import stuff and i don't recall getting to the bottom of it.
On Wed, Feb 14, 2018 at 2:27 PM, Moore, Branden James <bjm...@sandia.gov> wrote: > So I did a quick experiment of: > > --- a/gremlin-groovy/src/main/java/org/apache/tinkerpop/ > gremlin/groovy/jsr223/GremlinGroovyScriptEngine.java > +++ b/gremlin-groovy/src/main/java/org/apache/tinkerpop/ > gremlin/groovy/jsr223/GremlinGroovyScriptEngine.java > - > CoreGremlinPlugin.instance().getCustomizers("gremlin-groovy").ifPresent(c > -> listOfCustomizers.addAll(Arrays.asList(c))); > + > CoreGremlinPlugin.instance().getCustomizers("gremlin-groovy").ifPresent(c > -> listOfCustomizers.addAll(0, Arrays.asList(c))); > > > While this does allow my DSL's __ to be the one found, oddly, some other > static imports no longer appear in the interpreter; specifically 'label'. > (Referencing 'T.label' works fine.) It isn't that the symbol lookup finds > the incorrect class; I get the error "groovy.lang.MissingPropertyException: > No such property: label for class: Script2", however, some other enums (ie, > 'incr') are imported just fine. > > Any ideas why that would occur? > > On 2/14/18, 10:46 AM, "Stephen Mallette" <spmalle...@gmail.com> wrote: > > There was a time when I looked into that in pretty grave detail. I > don't > recall my findings exactly, but I obviously didn't come up with a nice > solution. I'm not sure that I ever became convinced that any of this > groovy > import stuff behaves in a completely deterministic way. I suppose you > could > try it out and see if that change helps or not.... > > On Wed, Feb 14, 2018 at 12:42 PM, Moore, Branden James < > bjm...@sandia.gov> > wrote: > > > Thanks for fixing issue #1. I figured that one would be easy to > fix. > > > > As for issue #2, I'm wondering if changing the > GremlinGroovyScriptEngine > > to add it's ImportCustomizer (line 247) to the beginning of the > list of > > customizers, rather than the end, would allow DSLs (and any other > imports) > > to override the default Gremlin imports. > > > > - Branden > > > > On 2/14/18, 8:23 AM, "Stephen Mallette" <spmalle...@gmail.com> > wrote: > > > > Oops - the `getAnonymousTraversalClass()` should get generated > > properly. I > > created this issue: > > > > https://issues.apache.org/jira/browse/TINKERPOP-1890 > > > > which i already pushed a fix for: > > > > https://github.com/apache/tinkerpop/commit/ > > 2d7113aaa166b69a8503be27aebf36a8063b82bd > > > > your second problem....hmm - not sure what to do with that. > Trying to > > think > > of what could be done: > > > > 1. Ugly, but you could always specify the package > name......super gross > > 2. You could statically import your anonymous steps in a custom > import > > in > > Gremlin Server so instead of g.persons(__.xxx()) you would do > > g.persons(xxx()). > > 3. It would be a bit of work, but I suppose the DSL processor > could be > > modified somehow to allow you to rename the DSL double underscore > > class to > > something else (triple underscore ??? hehe), then you could just > > import it. > > > > Seems like option 2 would work best in the short term. > > > > > > > > > > > > On Tue, Feb 13, 2018 at 6:50 PM, Moore, Branden James < > > bjm...@sandia.gov> > > wrote: > > > > > Hi all, > > > > > > We are using the @GremlinDsl annotation to extend the Gremlin > > language > > > into our own DSL. I’ve run into two issues with anonymous > > traversals so > > > far that I’d like to bring up. One has a work-around, the > other, I > > have > > > not yet found a work-around. > > > > > > First (the one with the work-around): The <DSL>TraversalSource > > class that > > > is generated does not override the > ‘getAnonymousTraversalClass()’ > > method of > > > GraphTraversalSource, so the returned class is > > org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.__ > > > rather than the auto-generated, DSL-specific version of ‘__’. > > This can > > > be worked around by specifying your own base class that > implementes > > > ‘getAnonymousTraversalClass()’. However, this still > requires some > > > oddities, as the code generator interprets the method as a > method to > > be > > > auto-generated. My solution was to create two levels of > > inheritance: > > > > > > 1. MyDSLTraversalSourceDsl0 extends GraphTraversalSource, > and > > > implements ‘getAnonymousTraversalClass()’ > > > 2. MyDSLTraversalSourceDsl1 extends > MyDSLTraversalSourceDsl0, but > > does > > > nothing else > > > 3. MyDSLTraversalDSL extends GraphTRaversal.Admin<S,E>, and > uses > > the > > > @GremlinDsl(traversalSource = “MyDSLTraversalDSL1”) > > > > > > > > > > > > The second issue, for which I have not yet found a > work-around, is > > that > > > when using the Gremlin-Groovy scriptEngine as a Gremlin > Server, and > > sending > > > “gremlin” to the server (rather than bytecode), anonymous > traversals > > do not > > > find my DSL’s implementation of __, but rather the TinkerPop > __. > > I’ve > > > added my ‘__’ to the ImportGremlinPlugin’s classImports. This > is > > > sufficient for sending bytecode and having my __ found. > However, > > when > > > sending “gremlin” to the Session Processor, with “eval” as the > OP, > > the > > > groovy class cache finds TinkerPop’s __ rather than my __. > This is > > > appears to be because in GremlinGroovyScriptEngine, the > > CoreGremlinPlugin’s > > > customizers get added last to the list of ImportCustomizers. > As it > > is > > > processed last, when building the map of class names to > > fully-qualified > > > class names, the Gremlin ‘__’ key overwrites the ‘__’ key > which was > > > specified to be imported in the server’s YAML. I also came > across > > an > > > interesting comment in ‘ImportGroovyCustomizer’ which forces an > > import of > > > Tinkerpop’s ‘__’ as well. > > > > > > It's quite possible that I’m missing something, if so, could > you > > please > > > point me to how one is supposed to enable a custom DSL with the > > > Gremlin-Groovy script engine? > > > > > > Thanks much, > > > > > > * Branden > > > > > > > > > > > > > > >