java: package org.apache.tinkerpop.shaded.jackson.core does not exist
While trying to
mvn clean install with jdk11, I ran into the above error using the master branch. Any idea?13 Replies
what happens if you do
mvn clean install -pl gremlin-shaded first and then try to build the whole thing? you shouldn't have to do this of course but i'm not sure what might be wrong.actually
mvn clean intall works. But importing the project into intellij and then running any test fails at
after following the step above to configure intellj, I ran into the following when running a Gherkin test:
Any idea?
like all gremlin test suite tests they cant be run directly because they need a graph implementation to run. in the TibkerPop code base you can use TinkerGraph to be that implementation. run TinkerGraphFeatureTest in tinkergraph-gremlin to run those gherkin tests with TibkerGraph
If I have an implementation in Rust, do you think there is a way I can inject the dependency into the current Gherkin test suite for Gremlin?
I am thinking about whether I can reuse the parser and query plan optimizer of TinkerPop (if there is any) for the execution engine I am working on
TinkerGraph sounds like an execution engine for Gremlin? Is there a way to use it in a standalone way?
im not sure what you mean. what is the nature of your rust implementation?
It started as a general purpose matching engine like what
.match() can do in Gremlin
Since it has the Graph API to traverse the graph and a postprocessing part to process tables, I expects it can cover most of the Gremlin features
so I am thinking about whether people can reuse the parser and query optimizer from Gremlin project so I can use them to build a Gremlin frontendif i understand correctly you have written a Gremlin execution engine in Rust. I presume it uses the antlr grammar in gremlin-language in some way? in any event, i'm not sure how you would use much of what we have in TinkerPop given that all our code is JVM oriented for the Gremlin query processing, graph API interfaces and the default reference implementation of TinkerGraph. The antlr grammar is something i could see you using and I could see you using the gherkin feature tests, which i guess is what you are trying to do. you'd need to rig up y our own classes for executing those gherkin tests over your Rust implementation and do so natively in Rust. It's not too hard to do I don't think - note we've done it for all our non-JVM implementations so doing it for Rust shouldn't be too hard but it also isn't a small bit of work you could do in a few hours. i could probably say more if i'm on the right track with what you are hoping to accomplish but i'll let you confirm before i type too much more in case i'm way off
If the physical plan can be serialized and sent over, the front end parser and the query plan optimizer can be in JVM. We just need to send the serialized physical plan, say a Json file to represent the physical plan , over for the execution engine
I think we are on the same page
If what I think is doable, I dont need to start from the antlr grammar
If the dependency injection part can be handled properly so that the non-JVM execution engine can be injected into the existing test suite, I can imagine we can even reuse the gherkins test suite in JVM
i think you're saying that you would want to send a Gremlin string to Gremlin Server and get back a serialized representation of it. i suppose that is possible by sending a script and returning
i think that you would need some additional changes for any of this to work as you're thinking and it does conflict a bit with ongoing thinking around the support of
Bytecode as GraphSON. that is an extremely narrow use case as i dont think there would be any other value there aside from this case, i.e. some sort of language interop with a different processing engine off the JVM. Of course, that only gets you Gremlin parsed into a JSON form as it was written. At that point, no optimization strategies are applied and in any event those strategies would include ones specific to particular graph systems which likely would not apply to whatever graph system you were executing on (e.g. the inclusion of a TinkerGraphStep, replacing GraphStep won't have any meaning in your Rust environment).i think that you would need some additional changes for any of this to work as you're thinking and it does conflict a bit with ongoing thinking around the support of
Bytecode as a mechanism for sending traversals to the server (it's primary purpose). Anyway, here's what Bytecode looks like as GraphSON: https://tinkerpop.apache.org/docs/current/dev/io/#_bytecode_2sending a script and returning Bytecode as GraphSONThe GraphSON seems to be a physical plan an execution engine can interpret? From your link, I do not seem to see how such format can represent the physical plan of a query like I do think the physical plan can be represented in JSON though.
valueFrom the implementer perspective, the value is that TinkerPop can stay as the de-facto standard parser and query plan optimizer for Gremlin and provide the Gherkin test suite for correctness verification. It does not seem meaningful to reinvent these nice things. There are some implementors out there who want to support Gremlin but cannot use the reference implementation
TinkerGraph for various reasons, say, the need of going distributed, supporting mix of OLAP and OLTP workload (HTAP), new hardware optimization like better networking, storage and compute hardwares. These are not things we can add to a JVM implementationwhen you run some Gremlin through the the ANTLR parser it simply constructs a
Traversal object by mapping to the methods in of the same name in GraphTraversalSouce and GraphTraversal. In doing that the Traversal maintains a Bytecode representation of those steps that are called. When the Traversal is executed, various TraversalStrategy objects are applied to the Traversal to rewrite in in a more optimal way to improve performance, like g.V().out().count() would become g.V().outE().count(). It is through TraversalStrategy implementations that indices and other graph implementation specific optimizations can be included as part of the execution. There's not really a physical plan to see beyond what is provided by the construction of the traversal after parsing. I shared Bytecode because that's likely the closest you could get as a portable version of a Traversal as a way to reuse JVM parsing.