I think I can get to that later this week. I could push Chris' work into a new branch on the new repo and then put a PR in so we could come to some consensus on if that's a good starting point?

One last question, mainly for Expero folks. Is anyone already intending to make the initial commit? I have a conference this week, but can work on this next week if not.

+1. I like CTR for upstream merges to help streamline the process. I personally really like getting a second set of eyes on my commits and enjoy the feedback. That being said I've gotten some great

https://github.com/JanusGraph/janusgraph-ambari is created

https://github.com/JanusGraph/janusgraph-docker is created

There hasn't been any negative responses on this thread. I will submit a PR today to update the PR docs to outline these updates in policy. 1. CTR is already part of our policy a. Committers are

JanusGraph simply lacks the required GraphSON serializers and deserializers for predicates. I created #1060 to track this issue and fixed it with PR #1061 which was merged into master and not into the

Yeah, a stack trace from Gremlin will us help to see what is going on. That should not be a dependency in that case. Thanks, Jerry

And, the following are serializers registered in my gremlin-server.yaml for JanusGraph 0.2.1 (I use the default packeged set of serializers): serializers: - { className:

Hi All, So as you all know I've been developing Client drivers for JanusGraph. I was able to test my initial version of library against JanusGraph 0.3.0 which uses TP 3.3.3. I now want to test the

Ah. I think we might be wrong in our understanding there. As I was trying to read the graph data from my underlaying backend (Cassandra) and not any Graph stored on HDFS using JanusGraph's

Will there be a new review and approval policy? I believe it should be implemented. +1 for all discussed above.

The need for Hadoop conf (only the hdfs conf) is to read from or write to graph data files on hdfs. Direct interacting with JanusGraph backend without involving any graph data files on hdfs won't need

@Jerry: JanusGraph doesn't need Hadoop Cluster to run OLAP yes, but doesn't JanusGraph needs to point to a live Hadoop Cluster by setting HADOOP_CONF_DIR in CLASSPATH? I guess that was my

That being said, to be clear, you don't need a Hadoop cluster or any kind if that is what you mean. JanusGraph packages the Hadoop jars it needs. That is all you need to run SparkComputer on

I don't think it will work. Spark needs input (to read graph data) and output (to write graph data). JanusGraph currently only provides Hadoop InputFormat based reading from JanusGraph for OLAP. In

Hi All, I am pretty new to Janusgraph and want to get some suggestions from you. Previously I posted a question about using ES as backend storage, and got some good feedback from Jason (Thanks!).

Hello, I see that in the class "ElasticSearchIndex" in the method "pushMapping(String store, String key, KeyInformation information)" we ignore any custom properties from "KeyInformation information".

As Debasish said. Please add to the Issue if you have any additional comments. Regarding Hadoop 3.x support, the latest Apache Tinkerpop is still on Hadoop version 2.7.x and has not claim support

Hi Jagadeesh, Please follow the github issue to track support for HBase 2.x for JanusGraph.