Date   

0.2.0-SNAPSHOT updates?

woj...@...
 

Hello,

I've been waiting for some features recently added to Janus to give it a go.
But it seems that last snapshot available for 0.2.0 release is a month old (24 May 2017):

https://oss.sonatype.org/content/repositories/snapshots/org/janusgraph/janusgraph-core/0.2.0-SNAPSHOT/

I know I could built it from source and host it somewhere privately, but I kind of defeats the purpose of having dev snapshots in the first place.

Can we expect some updates to this snapshot anytime soon?

Having this automated and pushed on regular basis would be great too :)


Re: Compiling locally with gremlin-core 3.3.0-SNAPSHOT

Kedar Mhaswade <ke...@...>
 

Hi Sjudeng,

Ah, I missed that one. Now I am able to run SGC, but I am still seeing issues with class loading [1]. Am I to copy some jar files from somewhere to the lib-folder of JG workspace (local clone)?

Is it possible for you to share with me the properties file with which you initialize the graph?
My config file is [2].

Thanks,
Kedar

[1]

Caused by: java.lang.ClassNotFoundException: org.apache.spark.deploy.yarn.YarnSparkHadoopUtil

at java.net.URLClassLoader.findClass(URLClassLoader.java:381)

at java.lang.ClassLoader.loadClass(ClassLoader.java:424)

at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)

at java.lang.ClassLoader.loadClass(ClassLoader.java:357)

at java.lang.Class.forName0(Native Method)

at java.lang.Class.forName(Class.java:348)

at org.apache.spark.util.Utils$.classForName(Utils.scala:228)

at org.apache.spark.deploy.SparkHadoopUtil$.liftedTree1$1(SparkHadoopUtil.scala:413)

[2]

#

# Hadoop Graph Configuration

#

gremlin.graph=org.apache.tinkerpop.gremlin.hadoop.structure.HadoopGraph

# with my changes

gremlin.hadoop.graphInputFormat=org.janusgraph.hadoop.formats.cassandra.Cassandra3InputFormat

gremlin.hadoop.graphOutputFormat=org.apache.tinkerpop.gremlin.hadoop.structure.io.gryo.GryoOutputFormat


gremlin.hadoop.jarsInDistributedCache=true

gremlin.hadoop.inputLocation=none

gremlin.hadoop.outputLocation=output


#

# JanusGraph Cassandra InputFormat configuration

#

janusgraphmr.ioformat.conf.storage.backend=cassandrathrift

janusgraphmr.ioformat.conf.storage.hostname=<ip1, ip2...>

janusgraphmr.ioformat.conf.storage.port=9160

janusgraphmr.ioformat.conf.storage.cassandra.keyspace=janusgraph

# more config

# default for timeout: 10000 ms = 10 s

janusgraphmr.ioformat.conf.storage.connection-timeout=100000 


#

# Apache Cassandra InputFormat configuration

#

cassandra.input.partitioner.class=org.apache.cassandra.dht.Murmur3Partitioner


#

# SparkGraphComputer Configuration

#

spark.master=yarn

spark.serializer=org.apache.spark.serializer.KryoSerializer

spark.executor.instances=100


# from vtslab on GH

spark.app.name=uGraph

spark.ui.port=4050

spark.executor.memory=2g

spark.executorEnv.SPARK_CONF_DIR=/etc/spark/conf

spark.executorEnv.HADOOP_CONF_DIR=/etc/hadoop/conf



On Wed, Jun 21, 2017 at 3:05 PM, sjudeng <sju...@...> wrote:
Hi Kedar,

I think you just need to load the spark plugin.

gremlin> :plugin use tinkerpop.spark

On Wednesday, June 21, 2017 at 3:26:15 PM UTC-5, Kedar Mhaswade wrote:
Hi sjudeng,

Is this update missing SparkGraphComputer? After building tp33 branch, I get the following on gremlin console:

gremlin> graph1 = GraphFactory.open('conf/hadoop-graph/read-cassandra.properties')

==>hadoopgraph[cassandrainputformat->gryooutputformat]

gremlin> olap = graph1.traversal().withComputer(SparkGraphComputer)

No such property: SparkGraphComputer for class: groovysh_evaluate

What am I missing? How were you able to run the queries with Spark/Yarn?


Regards,

Kedar


On Wed, Jun 21, 2017 at 10:01 AM, Kedar Mhaswade <k...@...> wrote:


On Wed, Jun 21, 2017 at 4:01 AM, sjudeng <s...@...> wrote:
In case there's interest the branch in https://github.com/sjudeng/janusgraph/tree/tp33 has some very early work on building JanusGraph with TinkerPop 3.3.0-SNAPSHOT. At this point it's compiling and I've tested OLAP traversals and BulkLoaderVertexProgram without issue using Spark 2.1 on Yarn (Cloudera) with some small test graphs in HBase. Currently only in memory TinkerPop unit test suites have been run and there are a handful of failures related to profiling, graph I/O involving geometries and graph computer. The couple graph computer test failures may just be issues with FulgoraGraphComputer (e.g. not something more general that might affect SparkGraphComputer) but I'm not sure yet. I'll be pushing more commits and likely squashing/rebasing along the way so keep that in mind if pulling.

Thanks sjudeng!

I will take a look at the changes and try out some graphs against a Cassandra-3 backend (which means it will need my PR). Is there any chance that this will become a part of JanusGraph 0.2.0 release?

Regards,
Kedar
 

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Compiling locally with gremlin-core 3.3.0-SNAPSHOT

sjudeng <sju...@...>
 

Hi Kedar,

I think you just need to load the spark plugin.

gremlin> :plugin use tinkerpop.spark


On Wednesday, June 21, 2017 at 3:26:15 PM UTC-5, Kedar Mhaswade wrote:
Hi sjudeng,

Is this update missing SparkGraphComputer? After building tp33 branch, I get the following on gremlin console:

gremlin> graph1 = GraphFactory.open('conf/hadoop-graph/read-cassandra.properties')

==>hadoopgraph[cassandrainputformat->gryooutputformat]

gremlin> olap = graph1.traversal().withComputer(SparkGraphComputer)

No such property: SparkGraphComputer for class: groovysh_evaluate

What am I missing? How were you able to run the queries with Spark/Yarn?


Regards,

Kedar


On Wed, Jun 21, 2017 at 10:01 AM, Kedar Mhaswade <k...@...> wrote:


On Wed, Jun 21, 2017 at 4:01 AM, sjudeng <s...@...> wrote:
In case there's interest the branch in https://github.com/sjudeng/janusgraph/tree/tp33 has some very early work on building JanusGraph with TinkerPop 3.3.0-SNAPSHOT. At this point it's compiling and I've tested OLAP traversals and BulkLoaderVertexProgram without issue using Spark 2.1 on Yarn (Cloudera) with some small test graphs in HBase. Currently only in memory TinkerPop unit test suites have been run and there are a handful of failures related to profiling, graph I/O involving geometries and graph computer. The couple graph computer test failures may just be issues with FulgoraGraphComputer (e.g. not something more general that might affect SparkGraphComputer) but I'm not sure yet. I'll be pushing more commits and likely squashing/rebasing along the way so keep that in mind if pulling.

Thanks sjudeng!

I will take a look at the changes and try out some graphs against a Cassandra-3 backend (which means it will need my PR). Is there any chance that this will become a part of JanusGraph 0.2.0 release?

Regards,
Kedar
 

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



Re: Compiling locally with gremlin-core 3.3.0-SNAPSHOT

Kedar Mhaswade <ke...@...>
 

Hi sjudeng,

Is this update missing SparkGraphComputer? After building tp33 branch, I get the following on gremlin console:

gremlin> graph1 = GraphFactory.open('conf/hadoop-graph/read-cassandra.properties')

==>hadoopgraph[cassandrainputformat->gryooutputformat]

gremlin> olap = graph1.traversal().withComputer(SparkGraphComputer)

No such property: SparkGraphComputer for class: groovysh_evaluate

What am I missing? How were you able to run the queries with Spark/Yarn?


Regards,

Kedar


On Wed, Jun 21, 2017 at 10:01 AM, Kedar Mhaswade <ke...@...> wrote:


On Wed, Jun 21, 2017 at 4:01 AM, sjudeng <sju...@...> wrote:
In case there's interest the branch in https://github.com/sjudeng/janusgraph/tree/tp33 has some very early work on building JanusGraph with TinkerPop 3.3.0-SNAPSHOT. At this point it's compiling and I've tested OLAP traversals and BulkLoaderVertexProgram without issue using Spark 2.1 on Yarn (Cloudera) with some small test graphs in HBase. Currently only in memory TinkerPop unit test suites have been run and there are a handful of failures related to profiling, graph I/O involving geometries and graph computer. The couple graph computer test failures may just be issues with FulgoraGraphComputer (e.g. not something more general that might affect SparkGraphComputer) but I'm not sure yet. I'll be pushing more commits and likely squashing/rebasing along the way so keep that in mind if pulling.

Thanks sjudeng!

I will take a look at the changes and try out some graphs against a Cassandra-3 backend (which means it will need my PR). Is there any chance that this will become a part of JanusGraph 0.2.0 release?

Regards,
Kedar
 

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



Re: Compiling locally with gremlin-core 3.3.0-SNAPSHOT

Kedar Mhaswade <ke...@...>
 



On Wed, Jun 21, 2017 at 4:01 AM, sjudeng <sju...@...> wrote:
In case there's interest the branch in https://github.com/sjudeng/janusgraph/tree/tp33 has some very early work on building JanusGraph with TinkerPop 3.3.0-SNAPSHOT. At this point it's compiling and I've tested OLAP traversals and BulkLoaderVertexProgram without issue using Spark 2.1 on Yarn (Cloudera) with some small test graphs in HBase. Currently only in memory TinkerPop unit test suites have been run and there are a handful of failures related to profiling, graph I/O involving geometries and graph computer. The couple graph computer test failures may just be issues with FulgoraGraphComputer (e.g. not something more general that might affect SparkGraphComputer) but I'm not sure yet. I'll be pushing more commits and likely squashing/rebasing along the way so keep that in mind if pulling.

Thanks sjudeng!

I will take a look at the changes and try out some graphs against a Cassandra-3 backend (which means it will need my PR). Is there any chance that this will become a part of JanusGraph 0.2.0 release?

Regards,
Kedar
 

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Compiling locally with gremlin-core 3.3.0-SNAPSHOT

sjudeng <sju...@...>
 

In case there's interest the branch in https://github.com/sjudeng/janusgraph/tree/tp33 has some very early work on building JanusGraph with TinkerPop 3.3.0-SNAPSHOT. At this point it's compiling and I've tested OLAP traversals and BulkLoaderVertexProgram without issue using Spark 2.1 on Yarn (Cloudera) with some small test graphs in HBase. Currently only in memory TinkerPop unit test suites have been run and there are a handful of failures related to profiling, graph I/O involving geometries and graph computer. The couple graph computer test failures may just be issues with FulgoraGraphComputer (e.g. not something more general that might affect SparkGraphComputer) but I'm not sure yet. I'll be pushing more commits and likely squashing/rebasing along the way so keep that in mind if pulling.


Dealing with org.apache.thrift.transport.TTransportException

Nigel Brown <nigel...@...>
 

The below was a problem in titan and is still in janus, under some circumstances

3:18:37 WARN  org.apache.hadoop.mapred.LocalJobRunner  - job_local1757555819_0001
java
.lang.Exception: java.lang.RuntimeException: org.apache.thrift.transport.TTransportException: Frame size (19784570) larger than max length (15728640)!
 at org
.apache.hadoop.mapred.LocalJobRunner$Job.run(LocalJobRunner.java:403)
Caused by: java.lang.RuntimeException: org.apache.thrift.transport.TTransportException: Frame size (19784570) larger than max length (15728640)!


I can up the max frame size in the config

storage.cassandra.frame-size-mb=50

To get over the problem, but this is only pushing the problem further out. Also, having massive frame sizes can send cassandra into a gc loop which makes it grind to a halt.

To make janus scalable, I need a solution that does not depend on an arbitrary limit.

Two solutions spring to mind
1. Fragment and reassemble, like other transport (e.g. tcp)
2. Node partitioning, where large rows in cassandra are split

I haven't really looked at the janus code yet, and both of these approaches may be entirely loopy, so the questions here are

1. Are there any comments on either approach?
2. Is anyone doing any similar work?
3. Are there other other approaches that circumvent this problem? (would this still be a problem with a CQL driver?)


Many thanks for any comments.




Re: [DISCUSS] Splitting janusgraph-cassandra

sjudeng <sju...@...>
 

Hi Samant,

Are you still able to move forward with getting your work on this submitted? If so do you want to call a vote on the proposed refactoring or do you want me to? One way or another I think the refactoring is definitely needed. It came up in a recent PR where configuration needed to be duplicated in janusgraph-cassandra and janusgraph-cql because of the current state of things.

Thanks!


Re: Compiling locally with gremlin-core 3.3.0-SNAPSHOT

sjudeng <sju...@...>
 

Yes. I think the current near term focus is moving JanusGraph towards a 0.2.0 release compatible with TinkerPop 3.2.5.


On Friday, June 16, 2017 at 11:02:59 PM UTC-5, Kedar Mhaswade wrote:
I am not sure if you guys are aware and perhaps it is not an immediate concern, but it seems that if one tries to first compile the apache tinkerpop master (which is at 3.3.0-SNAPSHOT) and use it in a local build then JanusGraph build fails [1].

It appears that there are a few incompatible changes from 3.2.5 to 3.3.0-SNAPSHOT for tinkerpop.

Am I missing something or is this expected?

Regards,
Kedar

PS - I was trying this because I need to test out the Spark-2 for SparkGraphComputer. Tinkerpop master has been updated to use Spark-2.

[1]

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project janusgraph-core: Compilation failure: Compilation failure: 

[ERROR] /home/kedar/uber-janusgraph/janusgraph-core/src/main/java/org/janusgraph/core/JanusGraph.java:[31,25] cannot find symbol

[ERROR]   symbol:   variable SUITE_STRUCTURE_PERFORMANCE

[ERROR]   location: @interface org.apache.tinkerpop.gremlin.structure.Graph.OptIn

[ERROR] /home/kedar/uber-janusgraph/janusgraph-core/src/main/java/org/janusgraph/core/JanusGraph.java:[34,25] cannot find symbol

[ERROR]   symbol:   variable SUITE_PROCESS_PERFORMANCE

[ERROR]   location: @interface org.apache.tinkerpop.gremlin.structure.Graph.OptIn

[ERROR] /home/kedar/uber-janusgraph/janusgraph-core/src/main/java/org/janusgraph/core/JanusGraph.java:[35,25] cannot find symbol

[ERROR]   symbol:   variable SUITE_GROOVY_PROCESS_STANDARD

[ERROR]   location: @interface org.apache.tinkerpop.gremlin.structure.Graph.OptIn

[ERROR] /home/kedar/uber-janusgraph/janusgraph-core/src/main/java/org/janusgraph/core/JanusGraph.java:[36,25] cannot find symbol

[ERROR]   symbol:   variable SUITE_GROOVY_PROCESS_COMPUTER

[ERROR]   location: @interface org.apache.tinkerpop.gremlin.structure.Graph.OptIn

[ERROR] /home/kedar/uber-janusgraph/janusgraph-core/src/main/java/org/janusgraph/core/JanusGraph.java:[37,25] cannot find symbol

[ERROR]   symbol:   variable SUITE_GROOVY_ENVIRONMENT

[ERROR]   location: @interface org.apache.tinkerpop.gremlin.structure.Graph.OptIn

[ERROR] /home/kedar/uber-janusgraph/janusgraph-core/src/main/java/org/janusgraph/core/JanusGraph.java:[38,25] cannot find symbol

[ERROR]   symbol:   variable SUITE_GROOVY_ENVIRONMENT_INTEGRATE

[ERROR]   location: @interface org.apache.tinkerpop.gremlin.structure.Graph.OptIn

[ERROR] /home/kedar/uber-janusgraph/janusgraph-core/src/main/java/org/janusgraph/core/JanusGraph.java:[39,25] cannot find symbol

[ERROR]   symbol:   variable SUITE_GROOVY_ENVIRONMENT_PERFORMANCE

[ERROR]   location: @interface org.apache.tinkerpop.gremlin.structure.Graph.OptIn


Re: Compiling locally with gremlin-core 3.3.0-SNAPSHOT

Kedar Mhaswade <ke...@...>
 

Thanks @sjudeng! 

I need to utilize Yarn support for SparkGraphComputer while upgrading Spark 2.0. It seems to me that this is an unexplored territory. For the Spark/TP upgrade in JG, are we going to stick to the plan outlined in the thread you pointed me to?

Regards,
Kedar


On Sat, Jun 17, 2017 at 5:35 AM, sjudeng <sju...@...> wrote:
Hi Kedar,

Yes this is expected. JanusGraph does not currently support TinkerPop 3.3. See some related discussion in https://groups.google.com/forum/#!topic/janusgraph-dev/cdZGlxWkEFc.


On Friday, June 16, 2017 at 11:02:59 PM UTC-5, Kedar Mhaswade wrote:
I am not sure if you guys are aware and perhaps it is not an immediate concern, but it seems that if one tries to first compile the apache tinkerpop master (which is at 3.3.0-SNAPSHOT) and use it in a local build then JanusGraph build fails [1].

It appears that there are a few incompatible changes from 3.2.5 to 3.3.0-SNAPSHOT for tinkerpop.

Am I missing something or is this expected?

Regards,
Kedar

PS - I was trying this because I need to test out the Spark-2 for SparkGraphComputer. Tinkerpop master has been updated to use Spark-2.

[1]

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project janusgraph-core: Compilation failure: Compilation failure: 

[ERROR] /home/kedar/uber-janusgraph/janusgraph-core/src/main/java/org/janusgraph/core/JanusGraph.java:[31,25] cannot find symbol

[ERROR]   symbol:   variable SUITE_STRUCTURE_PERFORMANCE

[ERROR]   location: @interface org.apache.tinkerpop.gremlin.structure.Graph.OptIn

[ERROR] /home/kedar/uber-janusgraph/janusgraph-core/src/main/java/org/janusgraph/core/JanusGraph.java:[34,25] cannot find symbol

[ERROR]   symbol:   variable SUITE_PROCESS_PERFORMANCE

[ERROR]   location: @interface org.apache.tinkerpop.gremlin.structure.Graph.OptIn

[ERROR] /home/kedar/uber-janusgraph/janusgraph-core/src/main/java/org/janusgraph/core/JanusGraph.java:[35,25] cannot find symbol

[ERROR]   symbol:   variable SUITE_GROOVY_PROCESS_STANDARD

[ERROR]   location: @interface org.apache.tinkerpop.gremlin.structure.Graph.OptIn

[ERROR] /home/kedar/uber-janusgraph/janusgraph-core/src/main/java/org/janusgraph/core/JanusGraph.java:[36,25] cannot find symbol

[ERROR]   symbol:   variable SUITE_GROOVY_PROCESS_COMPUTER

[ERROR]   location: @interface org.apache.tinkerpop.gremlin.structure.Graph.OptIn

[ERROR] /home/kedar/uber-janusgraph/janusgraph-core/src/main/java/org/janusgraph/core/JanusGraph.java:[37,25] cannot find symbol

[ERROR]   symbol:   variable SUITE_GROOVY_ENVIRONMENT

[ERROR]   location: @interface org.apache.tinkerpop.gremlin.structure.Graph.OptIn

[ERROR] /home/kedar/uber-janusgraph/janusgraph-core/src/main/java/org/janusgraph/core/JanusGraph.java:[38,25] cannot find symbol

[ERROR]   symbol:   variable SUITE_GROOVY_ENVIRONMENT_INTEGRATE

[ERROR]   location: @interface org.apache.tinkerpop.gremlin.structure.Graph.OptIn

[ERROR] /home/kedar/uber-janusgraph/janusgraph-core/src/main/java/org/janusgraph/core/JanusGraph.java:[39,25] cannot find symbol

[ERROR]   symbol:   variable SUITE_GROOVY_ENVIRONMENT_PERFORMANCE

[ERROR]   location: @interface org.apache.tinkerpop.gremlin.structure.Graph.OptIn

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Compiling locally with gremlin-core 3.3.0-SNAPSHOT

sjudeng <sju...@...>
 

Hi Kedar,

Yes this is expected. JanusGraph does not currently support TinkerPop 3.3. See some related discussion in https://groups.google.com/forum/#!topic/janusgraph-dev/cdZGlxWkEFc.


On Friday, June 16, 2017 at 11:02:59 PM UTC-5, Kedar Mhaswade wrote:
I am not sure if you guys are aware and perhaps it is not an immediate concern, but it seems that if one tries to first compile the apache tinkerpop master (which is at 3.3.0-SNAPSHOT) and use it in a local build then JanusGraph build fails [1].

It appears that there are a few incompatible changes from 3.2.5 to 3.3.0-SNAPSHOT for tinkerpop.

Am I missing something or is this expected?

Regards,
Kedar

PS - I was trying this because I need to test out the Spark-2 for SparkGraphComputer. Tinkerpop master has been updated to use Spark-2.

[1]

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project janusgraph-core: Compilation failure: Compilation failure: 

[ERROR] /home/kedar/uber-janusgraph/janusgraph-core/src/main/java/org/janusgraph/core/JanusGraph.java:[31,25] cannot find symbol

[ERROR]   symbol:   variable SUITE_STRUCTURE_PERFORMANCE

[ERROR]   location: @interface org.apache.tinkerpop.gremlin.structure.Graph.OptIn

[ERROR] /home/kedar/uber-janusgraph/janusgraph-core/src/main/java/org/janusgraph/core/JanusGraph.java:[34,25] cannot find symbol

[ERROR]   symbol:   variable SUITE_PROCESS_PERFORMANCE

[ERROR]   location: @interface org.apache.tinkerpop.gremlin.structure.Graph.OptIn

[ERROR] /home/kedar/uber-janusgraph/janusgraph-core/src/main/java/org/janusgraph/core/JanusGraph.java:[35,25] cannot find symbol

[ERROR]   symbol:   variable SUITE_GROOVY_PROCESS_STANDARD

[ERROR]   location: @interface org.apache.tinkerpop.gremlin.structure.Graph.OptIn

[ERROR] /home/kedar/uber-janusgraph/janusgraph-core/src/main/java/org/janusgraph/core/JanusGraph.java:[36,25] cannot find symbol

[ERROR]   symbol:   variable SUITE_GROOVY_PROCESS_COMPUTER

[ERROR]   location: @interface org.apache.tinkerpop.gremlin.structure.Graph.OptIn

[ERROR] /home/kedar/uber-janusgraph/janusgraph-core/src/main/java/org/janusgraph/core/JanusGraph.java:[37,25] cannot find symbol

[ERROR]   symbol:   variable SUITE_GROOVY_ENVIRONMENT

[ERROR]   location: @interface org.apache.tinkerpop.gremlin.structure.Graph.OptIn

[ERROR] /home/kedar/uber-janusgraph/janusgraph-core/src/main/java/org/janusgraph/core/JanusGraph.java:[38,25] cannot find symbol

[ERROR]   symbol:   variable SUITE_GROOVY_ENVIRONMENT_INTEGRATE

[ERROR]   location: @interface org.apache.tinkerpop.gremlin.structure.Graph.OptIn

[ERROR] /home/kedar/uber-janusgraph/janusgraph-core/src/main/java/org/janusgraph/core/JanusGraph.java:[39,25] cannot find symbol

[ERROR]   symbol:   variable SUITE_GROOVY_ENVIRONMENT_PERFORMANCE

[ERROR]   location: @interface org.apache.tinkerpop.gremlin.structure.Graph.OptIn


Compiling locally with gremlin-core 3.3.0-SNAPSHOT

tpr...@...
 

You can try to look at tinkerpop 3.3 release doc : https://github.com/apache/tinkerpop/blob/master/docs/src/upgrade/release-3.3.x.asciidoc you may have your answer.


Compiling locally with gremlin-core 3.3.0-SNAPSHOT

Kedar Mhaswade <ke...@...>
 

I am not sure if you guys are aware and perhaps it is not an immediate concern, but it seems that if one tries to first compile the apache tinkerpop master (which is at 3.3.0-SNAPSHOT) and use it in a local build then JanusGraph build fails [1].

It appears that there are a few incompatible changes from 3.2.5 to 3.3.0-SNAPSHOT for tinkerpop.

Am I missing something or is this expected?

Regards,
Kedar

PS - I was trying this because I need to test out the Spark-2 for SparkGraphComputer. Tinkerpop master has been updated to use Spark-2.

[1]

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project janusgraph-core: Compilation failure: Compilation failure: 

[ERROR] /home/kedar/uber-janusgraph/janusgraph-core/src/main/java/org/janusgraph/core/JanusGraph.java:[31,25] cannot find symbol

[ERROR]   symbol:   variable SUITE_STRUCTURE_PERFORMANCE

[ERROR]   location: @interface org.apache.tinkerpop.gremlin.structure.Graph.OptIn

[ERROR] /home/kedar/uber-janusgraph/janusgraph-core/src/main/java/org/janusgraph/core/JanusGraph.java:[34,25] cannot find symbol

[ERROR]   symbol:   variable SUITE_PROCESS_PERFORMANCE

[ERROR]   location: @interface org.apache.tinkerpop.gremlin.structure.Graph.OptIn

[ERROR] /home/kedar/uber-janusgraph/janusgraph-core/src/main/java/org/janusgraph/core/JanusGraph.java:[35,25] cannot find symbol

[ERROR]   symbol:   variable SUITE_GROOVY_PROCESS_STANDARD

[ERROR]   location: @interface org.apache.tinkerpop.gremlin.structure.Graph.OptIn

[ERROR] /home/kedar/uber-janusgraph/janusgraph-core/src/main/java/org/janusgraph/core/JanusGraph.java:[36,25] cannot find symbol

[ERROR]   symbol:   variable SUITE_GROOVY_PROCESS_COMPUTER

[ERROR]   location: @interface org.apache.tinkerpop.gremlin.structure.Graph.OptIn

[ERROR] /home/kedar/uber-janusgraph/janusgraph-core/src/main/java/org/janusgraph/core/JanusGraph.java:[37,25] cannot find symbol

[ERROR]   symbol:   variable SUITE_GROOVY_ENVIRONMENT

[ERROR]   location: @interface org.apache.tinkerpop.gremlin.structure.Graph.OptIn

[ERROR] /home/kedar/uber-janusgraph/janusgraph-core/src/main/java/org/janusgraph/core/JanusGraph.java:[38,25] cannot find symbol

[ERROR]   symbol:   variable SUITE_GROOVY_ENVIRONMENT_INTEGRATE

[ERROR]   location: @interface org.apache.tinkerpop.gremlin.structure.Graph.OptIn

[ERROR] /home/kedar/uber-janusgraph/janusgraph-core/src/main/java/org/janusgraph/core/JanusGraph.java:[39,25] cannot find symbol

[ERROR]   symbol:   variable SUITE_GROOVY_ENVIRONMENT_PERFORMANCE

[ERROR]   location: @interface org.apache.tinkerpop.gremlin.structure.Graph.OptIn


Re: Guided use of Lombok in JG?

Samik Raychaudhuri <sam...@...>
 

My thought exactly - oh well!!
Regards.
-Samik

On 07-Jun-17 6:31 AM, Terry Moschou wrote:

Too bad JanusGraph wasn't written in Scala - boilerplate is kinda Java's thing right haha ;-p



Re: [DISCUSS] Support for Solr 6

Alexander Patrikalakis <amcpatr...@...>
 

Let us time box this discussion. If in 48 hours there is no dissonance, we can merge the PR?


On Saturday, June 10, 2017 at 10:19:48 AM UTC+9, sjudeng wrote:
I tested the Solr 6.6.0 updates against earlier Solr server versions and with a couple exceptions it is backwards compatible with Solr server versions through 5.3.x. See pull request comment for details.


Re: Guided use of Lombok in JG?

Henry Saputra <henry....@...>
 

Sorry, I did not mean to sidetrack disucssion about adding Lombok semantics to JG code, especially in core modules.
I was trying to imply that adding "magic" annotation could cause hard to follow/debug compare to the ones defining interface such as with with protobuf.

But I am +1 with Kedar approaches for introducing pros/cons to introduce Lombok uses in JG codebase.

- Henry

On Fri, Jun 9, 2017 at 6:39 AM, Ted Wilmes <twi...@...> wrote:
I like your proposed steps 1 & 2 Kedar. If we decided to continue with it after step 2, I think we should go through and finish up refactoring all the other packages to use whichever pieces of Lombok we've decided on. If we piecemeal it in as we make other changes, I think we'll just end up with a confusing mishmash of coding styles.

--Ted


On Wednesday, June 7, 2017 at 1:58:25 PM UTC-5, Alexander Patrikalakis wrote:
What are the benefits for polyglot support Lombok lacks that JanusGraph-Core needs? I think a non-Java rewrite of JanusGraph is not on the radar of our short-term and medium-term roadmap.
Also, the service interface of JanusGraph is provided by Gremlin Server over HTTP and Websockets, not inside JanusGraph, so it also seems like supporting polyglot service front ends within JanusGraph-Core is out of scope.

On Tuesday, June 6, 2017 at 7:42:37 AM UTC-10, Henry Saputra wrote:
Thanks for taking the initiative, Kedar.

One problem from my experience with Lombok and other similar code generator-like framework its that it generates code that developers don't control without benefits for polyglot support like with Protobuf or Apache Thrift.

So, would love to see possible approach and which areas can be moved or leverage Lombok in JG codebase.

- Henry

On Tue, Jun 6, 2017 at 9:11 AM, 'Kedar Mhaswade' via JanusGraph developer list <jan...@...> wrote:
Dear Fellow JG developers,

Alex Patrikalakis (@amcp) thought (and I agree) that we should find out how this community thinks about a guided use of Project Lombok in JG codebase. IMO, we should perhaps define a subset of Lombok that are pretty useful at reducing the Java boilerplate and use the features from that subset consistently across the JG codebase.

I do not want this thread to become a flamewar, but if we all find Lombok as useful as others do, why not use its best parts while still retaining code clarity?

Depending upon your response, I will start two things:
1- a Wiki defining our approach/styleguide to Lombok's use in JG code. If we all feel that everything in Lombok (stable) could be used in JG code, then this wiki should say so, otherwise, it should encourage devs to use a few of its features and discourage them from using other (controversial) ones.
2- an issue that tries use of Lombok on a subset of packages. Others can then take up the use of Lombok in the areas they are familiar with.

Regards,
Kedar

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [DISCUSS] Support for Solr 6

sjudeng <sju...@...>
 

I tested the Solr 6.6.0 updates against earlier Solr server versions and with a couple exceptions it is backwards compatible with Solr server versions through 5.3.x. See pull request comment for details.


Re: Guided use of Lombok in JG?

Ted Wilmes <twi...@...>
 

I like your proposed steps 1 & 2 Kedar. If we decided to continue with it after step 2, I think we should go through and finish up refactoring all the other packages to use whichever pieces of Lombok we've decided on. If we piecemeal it in as we make other changes, I think we'll just end up with a confusing mishmash of coding styles.

--Ted


On Wednesday, June 7, 2017 at 1:58:25 PM UTC-5, Alexander Patrikalakis wrote:
What are the benefits for polyglot support Lombok lacks that JanusGraph-Core needs? I think a non-Java rewrite of JanusGraph is not on the radar of our short-term and medium-term roadmap.
Also, the service interface of JanusGraph is provided by Gremlin Server over HTTP and Websockets, not inside JanusGraph, so it also seems like supporting polyglot service front ends within JanusGraph-Core is out of scope.

On Tuesday, June 6, 2017 at 7:42:37 AM UTC-10, Henry Saputra wrote:
Thanks for taking the initiative, Kedar.

One problem from my experience with Lombok and other similar code generator-like framework its that it generates code that developers don't control without benefits for polyglot support like with Protobuf or Apache Thrift.

So, would love to see possible approach and which areas can be moved or leverage Lombok in JG codebase.

- Henry

On Tue, Jun 6, 2017 at 9:11 AM, 'Kedar Mhaswade' via JanusGraph developer list <jan...@...> wrote:
Dear Fellow JG developers,

Alex Patrikalakis (@amcp) thought (and I agree) that we should find out how this community thinks about a guided use of Project Lombok in JG codebase. IMO, we should perhaps define a subset of Lombok that are pretty useful at reducing the Java boilerplate and use the features from that subset consistently across the JG codebase.

I do not want this thread to become a flamewar, but if we all find Lombok as useful as others do, why not use its best parts while still retaining code clarity?

Depending upon your response, I will start two things:
1- a Wiki defining our approach/styleguide to Lombok's use in JG code. If we all feel that everything in Lombok (stable) could be used in JG code, then this wiki should say so, otherwise, it should encourage devs to use a few of its features and discourage them from using other (controversial) ones.
2- an issue that tries use of Lombok on a subset of packages. Others can then take up the use of Lombok in the areas they are familiar with.

Regards,
Kedar

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [DISCUSS] Support for Solr 6

Jerry He <jerr...@...>
 

Is the Solr 6 client compatible with Solr 5 backend?   Can we confirm and list the incompatibilities?
Is the Solr 5 client good and compatible with Solr 6 backend?  If yes, we have a less urgent need to go to Solr 6 in JanusGraph completely.


Thanks,

Jerry


On Thursday, June 8, 2017 at 12:41:26 PM UTC-7, Jason Plurad wrote:
pull request have been opened for Solr 6 support. Testing is being done to determine whether this will break the existing support for Solr 5.

As sjudeng mentioned "We don't currently do different releases for any of the indexing (or storage) backends, so would it be preferable just to update to latest in the Solr/Lucene 5.x stream for JanusGraph 0.2.x releases and save the update to 6.x for 0.3.x releases? Personally I'd prefer to get everything updated for 0.2.x and keep 0.1.x as the compatibility branch." I think that sounds like a decent plan.

Is there anybody running with in production with JanusGraph (or Titan) with Solr 5?
Other thoughts or feedback on the upgrade to Solr 6?

-- Jason


[DISCUSS] Support for Solr 6

Jason Plurad <plu...@...>
 

pull request have been opened for Solr 6 support. Testing is being done to determine whether this will break the existing support for Solr 5.

As sjudeng mentioned "We don't currently do different releases for any of the indexing (or storage) backends, so would it be preferable just to update to latest in the Solr/Lucene 5.x stream for JanusGraph 0.2.x releases and save the update to 6.x for 0.3.x releases? Personally I'd prefer to get everything updated for 0.2.x and keep 0.1.x as the compatibility branch." I think that sounds like a decent plan.

Is there anybody running with in production with JanusGraph (or Titan) with Solr 5?
Other thoughts or feedback on the upgrade to Solr 6?

-- Jason

1301 - 1320 of 1585