Date   

Re: 0.2.0-SNAPSHOT updates?

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

I've deployed snapshot updates to Sonatype for 0.2.0-SNAPSHOT and 0.1.2-SNAPSHOT.

-- Jason


On Friday, June 30, 2017 at 11:29:19 AM UTC-4, Austin Sharp wrote:
FWIW we're very eager to see new snapshots and hopefully an 0.2.0 release soon as well. Eager enough that we are working on a branch that works with the 0.2.0 snapshot, and debating whether we'd (if it takes too long) release with the 0.2.0 snapshot or backport some changes to a forked version of 0.1.1.

On Tuesday, June 27, 2017 at 9:08:54 AM UTC-7, Ted Wilmes wrote:
Hey Jason,
I think you should be good to go since you added your name to the list on this issue: https://github.com/janusgraph/janusgraph/issues/97. With Sonatype permissions you'll be able to deploy the snapshot. Since that doesn't include binaries at this point, I've used the GitHub release feature to upload snapshot binaries before.  If you try it out and run into any issues, let me know.

--Ted

On Monday, June 26, 2017 at 8:42:20 PM UTC-5, Jason Plurad wrote:
Thanks, Ted. Are there other committers that have authority to publish a snapshot? I'd be happy to be added to the list of publishers if we had a writeup on how to do it.

-- Jason

On Friday, June 23, 2017 at 12:38:58 PM UTC-4, Ted Wilmes wrote:
Hello,
We'll probably start working on a release candidate for 0.2.0 shortly so I'll get another snapshot published before that, and yes, agreed on the automation! That's something that we need to get in place.

--Ted

On Thursday, June 22, 2017 at 8:10:09 AM UTC-5, wojcik.w wrote:
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 :)


MapReduceIndexManagement - can anyone make it work?

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

Please see 
https://groups.google.com/forum/#!topic/janusgraph-users/aM9YThbqU-4
Has anyone made this work?
What conditions?
Which version?


Re: Gremlin-Python in JanusGraph

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

Hi John, you probably installed the wrong version of gremlin-python plugin. If you're using JanusGraph 0.1.1, the TinkerPop version is 3.2.3. If you're building master from source, it has TinkerPop 3.2.5 now.

Try this:

cd janusgraph-0.1.1-hadoop2
rm
-rf ext/gremlin-python/
bin
/gremlin-server.sh -i org.apache.tinkerpop gremlin-python 3.2.3

-- Jason


On Thursday, July 6, 2017 at 7:45:21 PM UTC-4, john.helmsen wrote:
Gentlemen and Ladies,

Thank you for your help with the previous difficulties that we have been having in configuring our system.  We have recently gotten JanusGraph running in Server mode with HBase, and it is working correctly.  However, we have recently tried to add gremlin-python access to the server, so that we can work with it via a python client.

We are following the instructions on this page, which we have established work correctly when interfacing with GremlinServer running TinkerGraph: http://tinkerpop.apache.org/docs/current/reference/#gremlin-python

The problem is that when running starting the JanusGraph server referencing the following file:
host: localhost
port: 8182
threadPoolWorker: 1
gremlinPool: 8
scriptEvaluationTimeout: 30000
graphs: {
  graph: conf/tinkergraph-empty.properties}
scriptEngines: {
  gremlin-groovy: {
    plugins: { org.apache.tinkerpop.gremlin.server.jsr223.GremlinServerGremlinPl
ugin: {},
               org.apache.tinkerpop.gremlin.tinkergraph.jsr223.TinkerGraphGremli
nPlugin: {},
               org.apache.tinkerpop.gremlin.jsr223.ImportGremlinPlugin: {classIm
ports: [java.lang.Math], methodImports: [java.lang.Math#*]},
               org.apache.tinkerpop.gremlin.jsr223.ScriptFileGremlinPlugin: {fil
es: [scripts/generate-modern.groovy]}}},
  gremlin-jython: {},
  gremlin-python: {}
}
serializers:
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV1
d0, config: { ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph.structure.
TinkerIoRegistryV1d0] }}            # application/vnd.gremlin-v1.0+gryo
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoLiteMessageSerializ
erV1d0, config: { ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph.struct
ure.TinkerIoRegistryV1d0] }}        # application/vnd.gremlin-v1.0+gryo-lite
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV1
d0, config: { serializeResultToString: true }}        # application/vnd.gremlin-
v1.0+gryo-stringd
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializ
erGremlinV1d0, config: { ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph
.structure.TinkerIoRegistryV1d0] }} # application/vnd.gremlin-v1.0+json
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializ
erGremlinV2d0, config: { ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph
.structure.TinkerIoRegistryV2d0] }} # application/vnd.gremlin-v2.0+json
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializ
erV3d0, config: { ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph.struct
ure.TinkerIoRegistryV1d0] }}        # application/json
metrics: {
  slf4jReporter: {enabled: true, interval: 180000}}
strictTransactionManagement: false
threadPoolBoss: 1
maxInitialLineLength: 4096
maxHeaderSize: 8192
maxChunkSize: 8192
maxContentLength: 65536
maxAccumulationBufferComponents: 1024
resultIterationBatchSize: 64


or this file:

host: localhost
port: 8182
scriptEvaluationTimeout: 30000
channelizer: org.apache.tinkerpop.gremlin.server.channel.WebSocketChannelizer
graphs: {
  graph: conf/gremlin-server/janusgraph-hbase-server.properties}
plugins:
  - janusgraph.imports
scriptEngines: {
  gremlin-groovy: {
    imports: [java.lang.Math],
    staticImports: [java.lang.Math.PI],
    scripts: [scripts/empty-sample.groovy]},
  gremlin-jython: {},
  gremlin-python: {}}
serializers:
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV1d0, config: { bufferSize: 8192, ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoLiteMessageSerializerV1d0, config: {ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV1d0, config: { serializeResultToString: true }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV1d0, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV2d0, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV1d0, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
processors:
  - { className: org.apache.tinkerpop.gremlin.server.op.session.SessionOpProcessor, config: { sessionTimeout: 28800000 }}
  - { className: org.apache.tinkerpop.gremlin.server.op.traversal.TraversalOpProcessor, config: { cacheExpirationTime: 600000, cacheMaxSize: 1000 }}
metrics: {
  consoleReporter: {enabled: true, interval: 180000},
  csvReporter: {enabled: true, interval: 180000, fileName: /tmp/gremlin-server-metrics.csv},
  jmxReporter: {enabled: true},
  slf4jReporter: {enabled: true, interval: 180000},
  gangliaReporter: {enabled: false, interval: 180000, addressingMode: MULTICAST},
  graphiteReporter: {enabled: false, interval: 180000}}
maxInitialLineLength: 4096
maxHeaderSize: 8192
maxChunkSize: 8192
maxContentLength: 65536
maxAccumulationBufferComponents: 1024
resultIterationBatchSize: 64
writeBufferLowWaterMark: 32768
writeBufferHighWaterMark: 65536
ssl: {
  enabled: false}


They give this error:
Exception in thread "main" java.lang.IncompatibleClassChangeError: Implementing class
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
        at org.apache.tinkerpop.gremlin.python.jsr223.GremlinJythonScriptEngine.<init>(GremlinJythonScriptEngine.java:86)
        at org.apache.tinkerpop.gremlin.python.jsr223.GremlinJythonScriptEngineFactory.getScriptEngine(GremlinJythonScriptEngineFactory.java:110)
        at org.apache.tinkerpop.gremlin.jsr223.DefaultGremlinScriptEngineManager.createGremlinScriptEngine(DefaultGremlinScriptEngineManager.java:420)
        at org.apache.tinkerpop.gremlin.jsr223.DefaultGremlinScriptEngineManager.getEngineByName(DefaultGremlinScriptEngineManager.java:215)
        at org.apache.tinkerpop.gremlin.groovy.engine.ScriptEngines.createScriptEngine(ScriptEngines.java:424)
        at org.apache.tinkerpop.gremlin.groovy.engine.ScriptEngines.reload(ScriptEngines.java:187)
        at org.apache.tinkerpop.gremlin.groovy.engine.GremlinExecutor.lambda$createScriptEngines$11(GremlinExecutor.java:408)
        at org.apache.tinkerpop.gremlin.groovy.engine.ScriptEngines.<init>(ScriptEngines.java:92)
        at org.apache.tinkerpop.gremlin.groovy.engine.GremlinExecutor.createScriptEngines(GremlinExecutor.java:404)
        at org.apache.tinkerpop.gremlin.groovy.engine.GremlinExecutor.<init>(GremlinExecutor.java:110)
        at org.apache.tinkerpop.gremlin.groovy.engine.GremlinExecutor.<init>(GremlinExecutor.java:74)
        at org.apache.tinkerpop.gremlin.groovy.engine.GremlinExecutor$Builder.create(GremlinExecutor.java:651)
        at org.apache.tinkerpop.gremlin.server.util.ServerGremlinExecutor.<init>(ServerGremlinExecutor.java:136)
        at org.apache.tinkerpop.gremlin.server.util.ServerGremlinExecutor.<init>(ServerGremlinExecutor.java:83)
        at org.apache.tinkerpop.gremlin.server.GremlinServer.<init>(GremlinServer.java:110)
        at org.apache.tinkerpop.gremlin.server.GremlinServer.main(GremlinServer.java:344)


I am not actually using gremlin-jython, so I did make sure to remove the gremlin-jython references from both files and test them as well.  The results are the same. My best guess is that there is an API for the plugins of gremlin-jython and gremlin-python that is not matching up with JanusGraph properly, but it is unclear how to fix this.  Would anyone have any ideas?

Note, I can connect to the gremlin server in python using gremlinclient, and I can send commands to the server using the standard gremlin console as a client, so the server is operational.

Gremlin-python is considerably easier to develop in and preferable, so does anyone know how to fix this?  Thank you for all your help!


Gremlin-Python in JanusGraph

john....@...
 

Gentlemen and Ladies,

Thank you for your help with the previous difficulties that we have been having in configuring our system.  We have recently gotten JanusGraph running in Server mode with HBase, and it is working correctly.  However, we have recently tried to add gremlin-python access to the server, so that we can work with it via a python client.

We are following the instructions on this page, which we have established work correctly when interfacing with GremlinServer running TinkerGraph: http://tinkerpop.apache.org/docs/current/reference/#gremlin-python

The problem is that when running starting the JanusGraph server referencing the following file:
host: localhost
port: 8182
threadPoolWorker: 1
gremlinPool: 8
scriptEvaluationTimeout: 30000
graphs: {
  graph: conf/tinkergraph-empty.properties}
scriptEngines: {
  gremlin-groovy: {
    plugins: { org.apache.tinkerpop.gremlin.server.jsr223.GremlinServerGremlinPl
ugin: {},
               org.apache.tinkerpop.gremlin.tinkergraph.jsr223.TinkerGraphGremli
nPlugin: {},
               org.apache.tinkerpop.gremlin.jsr223.ImportGremlinPlugin: {classIm
ports: [java.lang.Math], methodImports: [java.lang.Math#*]},
               org.apache.tinkerpop.gremlin.jsr223.ScriptFileGremlinPlugin: {fil
es: [scripts/generate-modern.groovy]}}},
  gremlin-jython: {},
  gremlin-python: {}
}
serializers:
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV1
d0, config: { ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph.structure.
TinkerIoRegistryV1d0] }}            # application/vnd.gremlin-v1.0+gryo
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoLiteMessageSerializ
erV1d0, config: { ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph.struct
ure.TinkerIoRegistryV1d0] }}        # application/vnd.gremlin-v1.0+gryo-lite
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV1
d0, config: { serializeResultToString: true }}        # application/vnd.gremlin-
v1.0+gryo-stringd
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializ
erGremlinV1d0, config: { ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph
.structure.TinkerIoRegistryV1d0] }} # application/vnd.gremlin-v1.0+json
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializ
erGremlinV2d0, config: { ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph
.structure.TinkerIoRegistryV2d0] }} # application/vnd.gremlin-v2.0+json
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializ
erV3d0, config: { ioRegistries: [org.apache.tinkerpop.gremlin.tinkergraph.struct
ure.TinkerIoRegistryV1d0] }}        # application/json
metrics: {
  slf4jReporter: {enabled: true, interval: 180000}}
strictTransactionManagement: false
threadPoolBoss: 1
maxInitialLineLength: 4096
maxHeaderSize: 8192
maxChunkSize: 8192
maxContentLength: 65536
maxAccumulationBufferComponents: 1024
resultIterationBatchSize: 64


or this file:

host: localhost
port: 8182
scriptEvaluationTimeout: 30000
channelizer: org.apache.tinkerpop.gremlin.server.channel.WebSocketChannelizer
graphs: {
  graph: conf/gremlin-server/janusgraph-hbase-server.properties}
plugins:
  - janusgraph.imports
scriptEngines: {
  gremlin-groovy: {
    imports: [java.lang.Math],
    staticImports: [java.lang.Math.PI],
    scripts: [scripts/empty-sample.groovy]},
  gremlin-jython: {},
  gremlin-python: {}}
serializers:
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV1d0, config: { bufferSize: 8192, ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoLiteMessageSerializerV1d0, config: {ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GryoMessageSerializerV1d0, config: { serializeResultToString: true }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV1d0, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerGremlinV2d0, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
  - { className: org.apache.tinkerpop.gremlin.driver.ser.GraphSONMessageSerializerV1d0, config: { ioRegistries: [org.janusgraph.graphdb.tinkerpop.JanusGraphIoRegistry] }}
processors:
  - { className: org.apache.tinkerpop.gremlin.server.op.session.SessionOpProcessor, config: { sessionTimeout: 28800000 }}
  - { className: org.apache.tinkerpop.gremlin.server.op.traversal.TraversalOpProcessor, config: { cacheExpirationTime: 600000, cacheMaxSize: 1000 }}
metrics: {
  consoleReporter: {enabled: true, interval: 180000},
  csvReporter: {enabled: true, interval: 180000, fileName: /tmp/gremlin-server-metrics.csv},
  jmxReporter: {enabled: true},
  slf4jReporter: {enabled: true, interval: 180000},
  gangliaReporter: {enabled: false, interval: 180000, addressingMode: MULTICAST},
  graphiteReporter: {enabled: false, interval: 180000}}
maxInitialLineLength: 4096
maxHeaderSize: 8192
maxChunkSize: 8192
maxContentLength: 65536
maxAccumulationBufferComponents: 1024
resultIterationBatchSize: 64
writeBufferLowWaterMark: 32768
writeBufferHighWaterMark: 65536
ssl: {
  enabled: false}


They give this error:
Exception in thread "main" java.lang.IncompatibleClassChangeError: Implementing class
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:467)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:368)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:362)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:361)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
        at org.apache.tinkerpop.gremlin.python.jsr223.GremlinJythonScriptEngine.<init>(GremlinJythonScriptEngine.java:86)
        at org.apache.tinkerpop.gremlin.python.jsr223.GremlinJythonScriptEngineFactory.getScriptEngine(GremlinJythonScriptEngineFactory.java:110)
        at org.apache.tinkerpop.gremlin.jsr223.DefaultGremlinScriptEngineManager.createGremlinScriptEngine(DefaultGremlinScriptEngineManager.java:420)
        at org.apache.tinkerpop.gremlin.jsr223.DefaultGremlinScriptEngineManager.getEngineByName(DefaultGremlinScriptEngineManager.java:215)
        at org.apache.tinkerpop.gremlin.groovy.engine.ScriptEngines.createScriptEngine(ScriptEngines.java:424)
        at org.apache.tinkerpop.gremlin.groovy.engine.ScriptEngines.reload(ScriptEngines.java:187)
        at org.apache.tinkerpop.gremlin.groovy.engine.GremlinExecutor.lambda$createScriptEngines$11(GremlinExecutor.java:408)
        at org.apache.tinkerpop.gremlin.groovy.engine.ScriptEngines.<init>(ScriptEngines.java:92)
        at org.apache.tinkerpop.gremlin.groovy.engine.GremlinExecutor.createScriptEngines(GremlinExecutor.java:404)
        at org.apache.tinkerpop.gremlin.groovy.engine.GremlinExecutor.<init>(GremlinExecutor.java:110)
        at org.apache.tinkerpop.gremlin.groovy.engine.GremlinExecutor.<init>(GremlinExecutor.java:74)
        at org.apache.tinkerpop.gremlin.groovy.engine.GremlinExecutor$Builder.create(GremlinExecutor.java:651)
        at org.apache.tinkerpop.gremlin.server.util.ServerGremlinExecutor.<init>(ServerGremlinExecutor.java:136)
        at org.apache.tinkerpop.gremlin.server.util.ServerGremlinExecutor.<init>(ServerGremlinExecutor.java:83)
        at org.apache.tinkerpop.gremlin.server.GremlinServer.<init>(GremlinServer.java:110)
        at org.apache.tinkerpop.gremlin.server.GremlinServer.main(GremlinServer.java:344)


I am not actually using gremlin-jython, so I did make sure to remove the gremlin-jython references from both files and test them as well.  The results are the same. My best guess is that there is an API for the plugins of gremlin-jython and gremlin-python that is not matching up with JanusGraph properly, but it is unclear how to fix this.  Would anyone have any ideas?

Note, I can connect to the gremlin server in python using gremlinclient, and I can send commands to the server using the standard gremlin console as a client, so the server is operational.

Gremlin-python is considerably easier to develop in and preferable, so does anyone know how to fix this?  Thank you for all your help!


Re: [DISCUSS] Splitting janusgraph-cassandra

Samant Maharaj <samant...@...>
 

I'm now working on bringing the branch up to date against master and will raise the PR as soon as it's ready.

There've been a few changes since I did that initial work so it might take a short while to get it all squared away.

Regards,
Samant 


On Friday, 30 June 2017 14:38:03 UTC+12, sjudeng wrote:
Samant, It's been 5 days and no one has yelled too loud so I think it's reasonable to move forward with your PR on this if you're still up for it.

Ted, I don't think the reorganization here would cause any additional complexities with the eventual deprecation of Thrift. On the surface it seems to me it might make it simpler to carry out the deprecation/removal if the Thrift components are separated into a standalone module like here.

On Friday, June 23, 2017 at 10:45:50 PM UTC-5, sjudeng wrote:
All,

Samant has said he should be able to continue working on this effort. The current proposal is to refactor into the following structure.

├─ janusgraph-cassandra-parent/
│   ├── astyanax
│   ├── cql
│   ├── core
│   ├── embedded
│   ├── test
│   ├── thrift

+1 for me. I think it's a step in the right direction and I'd hate to see the work already done on this go to waste.

Jason, is this something that needs a separate vote thread or can the work/PR just move forward?

Samant, What do you think about Ted's question above?


On Saturday, June 17, 2017 at 12:28:41 PM UTC-5, sjudeng wrote:
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: Guided use of Lombok in JG?

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

To help spark discussion, I have proposed a use of Lombok here:
https://github.com/JanusGraph/janusgraph/pull/386

It reduces the janusgraph-core code base by 2327 lines.


On Tuesday, June 13, 2017 at 4:15:53 PM UTC+8, Samik R wrote:
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: Not able to 'addEdge' to 'CacheVertex'

Robert Dale <rob...@...>
 

One problem is that you are mixing APIs.  There is a direction in TinkerPop to even further separate the lines between user Traversal API and implementer Graph API. So it is highly recommend to stick with the user Traversal API.  Here is the equivalent gremlin:   

gremlin> g = TinkerGraph.open().traversal()
==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]

// starting with an empty graph
gremlin
> g.V()
gremlin
> g.E()

// get or create all vertexes and edges
gremlin
> g.inject(1).coalesce(
             __
.V().has('person','name','marko'),
             __
.addV('person').property('name','marko')).as('marko').
           coalesce
(
             __
.V().has('person','name','stephen'),
             __
.addV('person').property('name','stephen')).as('stephen').
           coalesce
(
             __
.in('knows').has('person','name','marko'),
             __
.addE('knows').from('marko'))
==>e[4][0-knows->2]

// show the path that now exists
gremlin
> g.V().outE().inV().path().by(valueMap(true))
==>[[name:[marko],label:person,id:0],[label:knows,id:4],[name:[stephen],label:person,id:2]]

// run it again, nothing new should be created
gremlin
> g.inject(1).coalesce(__.V().has('person','name','marko'),__.addV('person').property('name','marko')).as('marko').coalesce(__.V().has('person','name','stephen'),__.addV('person').property('name','stephen')).as('stephen').coalesce(__.in('knows').has('person','name','marko'),__.addE('knows').from('marko'))
==>v[0]

// show that only the previous relations exist, nothing new
gremlin
> g.V().outE().inV().path().by(valueMap(true))
==>[[name:[marko],label:person,id:0],[label:knows,id:4],[name:[stephen],label:person,id:2]]



-- 
Robert Dale


On Thursday, June 29, 2017 at 10:33:49 AM UTC-4, Teena K wrote:


down votefavorite

I have the below code in my java program that queries janusgraph to create vertices and edges if they don't exist already.

Vertex v1 = g.V().has(<key1>,<value1>).tryNext().orElseGet(()->
tx.addVertex(T.label,<label1>,<key1>,<value1>));
Vertex v2 = g.V().has(<key2>,<value2>).tryNext().orElseGet(()->
tx.addVertex(T.label,<label2>,<key2>,<value2>));

Vertices v1 and v2 get created if they don't exist.

..code to check if an edge exists between the two vertices..
..if there is no edge between the two, create an edge
v1.addEdge(<label3>,v2,<key3>,<value3>)

If the vertices are newly created, the code works fine and the edge also gets created between the two vertices. But if the vertices already exist in the DB, the edge doesn't get created. The difference I could find between the two cases is that v1 and v2 are of 'StandardVertex' type when they are newly created and they are of 'CacheVertex' type when they already exist. 'addEdge' is a valid method in both cases. Yet the edge doesn't get created.


Re: 0.2.0-SNAPSHOT updates?

Austin Sharp <austins...@...>
 

FWIW we're very eager to see new snapshots and hopefully an 0.2.0 release soon as well. Eager enough that we are working on a branch that works with the 0.2.0 snapshot, and debating whether we'd (if it takes too long) release with the 0.2.0 snapshot or backport some changes to a forked version of 0.1.1.


On Tuesday, June 27, 2017 at 9:08:54 AM UTC-7, Ted Wilmes wrote:
Hey Jason,
I think you should be good to go since you added your name to the list on this issue: https://github.com/janusgraph/janusgraph/issues/97. With Sonatype permissions you'll be able to deploy the snapshot. Since that doesn't include binaries at this point, I've used the GitHub release feature to upload snapshot binaries before.  If you try it out and run into any issues, let me know.

--Ted

On Monday, June 26, 2017 at 8:42:20 PM UTC-5, Jason Plurad wrote:
Thanks, Ted. Are there other committers that have authority to publish a snapshot? I'd be happy to be added to the list of publishers if we had a writeup on how to do it.

-- Jason

On Friday, June 23, 2017 at 12:38:58 PM UTC-4, Ted Wilmes wrote:
Hello,
We'll probably start working on a release candidate for 0.2.0 shortly so I'll get another snapshot published before that, and yes, agreed on the automation! That's something that we need to get in place.

--Ted

On Thursday, June 22, 2017 at 8:10:09 AM UTC-5, wojcik.w wrote:
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: Not able to 'addEdge' to 'CacheVertex'

David Pitera <piter...@...>
 

So I am not sure this will fix your problem, but please give it a try and let me know if it does:

When you instantiate a JanusGraph, [this transaction](https://github.com/JanusGraph/janusgraph/blob/master/janusgraph-core/src/main/java/org/janusgraph/graphdb/tinkerpop/JanusGraphBlueprintsGraph.java#L57) is opened for you. Rather than calling `JanusGraphTransaction tx = graph.newTransaction();`, why don't you emit that line and end your vertex/edge mutation code with `graph.tx().commit();`

I wonder if you have open, non-committed transactions running around; you can use [this method](https://github.com/JanusGraph/janusgraph/blob/master/janusgraph-core/src/main/java/org/janusgraph/graphdb/database/StandardJanusGraph.java#L306) to explore that possibility.

On Fri, Jun 30, 2017 at 12:43 AM, Teena K <avidlea...@...> wrote:
    
    JanusGraph graph = JanusGraphFactory.open("<path>/janusgraph/conf/janusgraph-cassandra.properties");
    JanusGraphTransaction tx = graph.newTransaction();    
    GraphTraversalSource g = graph.traversal();

    <code to add vertices and edges>

    tx.commit();

    The transaction is committed after all the code is executed.

On Thursday, June 29, 2017 at 10:04:20 PM UTC+5:30, Jason Plurad wrote:
You've left out some context here. How are g` and `tx` initialized? Where is the transaction committed?

On Thursday, June 29, 2017 at 10:33:49 AM UTC-4, Teena K wrote:


down votefavorite

I have the below code in my java program that queries janusgraph to create vertices and edges if they don't exist already.

Vertex v1 = g.V().has(<key1>,<value1>).tryNext().orElseGet(()->
tx.addVertex(T.label,<label1>,<key1>,<value1>));
Vertex v2 = g.V().has(<key2>,<value2>).tryNext().orElseGet(()->
tx.addVertex(T.label,<label2>,<key2>,<value2>));

Vertices v1 and v2 get created if they don't exist.

..code to check if an edge exists between the two vertices..
..if there is no edge between the two, create an edge
v1.addEdge(<label3>,v2,<key3>,<value3>)

If the vertices are newly created, the code works fine and the edge also gets created between the two vertices. But if the vertices already exist in the DB, the edge doesn't get created. The difference I could find between the two cases is that v1 and v2 are of 'StandardVertex' type when they are newly created and they are of 'CacheVertex' type when they already exist. 'addEdge' is a valid method in both cases. Yet the edge doesn't get created.

--
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] Splitting janusgraph-cassandra

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

Yeah, seems like it would be easier to tease apart the pieces we wanted to deprecate after this restructure so I think it makes good sense.

--Ted

On Thu, Jun 29, 2017 at 9:38 PM, sjudeng <sju...@...> wrote:
Samant, It's been 5 days and no one has yelled too loud so I think it's reasonable to move forward with your PR on this if you're still up for it.

Ted, I don't think the reorganization here would cause any additional complexities with the eventual deprecation of Thrift. On the surface it seems to me it might make it simpler to carry out the deprecation/removal if the Thrift components are separated into a standalone module like here.


On Friday, June 23, 2017 at 10:45:50 PM UTC-5, sjudeng wrote:
All,

Samant has said he should be able to continue working on this effort. The current proposal is to refactor into the following structure.

├─ janusgraph-cassandra-parent/
│   ├── astyanax
│   ├── cql
│   ├── core
│   ├── embedded
│   ├── test
│   ├── thrift

+1 for me. I think it's a step in the right direction and I'd hate to see the work already done on this go to waste.

Jason, is this something that needs a separate vote thread or can the work/PR just move forward?

Samant, What do you think about Ted's question above?


On Saturday, June 17, 2017 at 12:28:41 PM UTC-5, sjudeng wrote:
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!

--
You received this message because you are subscribed to a topic in the Google Groups "JanusGraph developer list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/janusgraph-dev/01ft3Fcoht4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Potential breaking changes in 0.2.0

david.c...@...
 

Yes I will add a logic to the getIndexStoreName() and also when JanusGraph query elasticsearch.

For the index delation work, if the index is not split, I can do it but it can take a long long time : it's depending of the number of document.

Le vendredi 30 juin 2017 04:31:27 UTC+2, sjudeng a écrit :
Although it's not as clean I think it's worth pursing the configuration option. You could call it something obtrusive like "index.elasicsearch.use-deprecated-multitype-index". If possible I think we'd want it to default to false so all new indices are split, but be treated as true if not present as in the case for legacy indices. As far as implementation complexity, would it maybe be as simple as adding logic to your ElasticSearchIndex.getIndexStoreName() method? Regarding your desired index deletion work, could you move forward if support is limited to single-type indices (e.g. so there'd be an additional conditional at https://github.com/JanusGraph/janusgraph/blob/bfa3c970555932d4983155168322f72297aaee85/janusgraph-core/src/main/java/org/janusgraph/graphdb/olap/job/IndexRemoveJob.java#L104)?

I'd still like to hear from others as well but this is what I'm thinking.

On Wednesday, June 28, 2017 at 11:47:49 AM UTC-5, Davide Bolcioni wrote:
I would expect an incompatible change to bump the major version, so 1.*

On Wed, Jun 28, 2017 at 9:00 AM, david.clement90 via JanusGraph developer list <jan...@...> wrote:
I add this thread to discuss about breaking change in 0.2.0 with this PR https://github.com/JanusGraph/janusgraph/pull/336.

This PR add a breaking change for Elasticsearch backend because it Elasticsearch split index into N indexes.
To deals with this, we have three options :
  1.  0.2.0 is not compatible with 0.1.x
  2. We create a script to migrate index.
  3. We make the configuration switch.

But, for me 0.2.0 is already not compatible with 0.1.x because Geoshape serialization (https://github.com/JanusGraph/janusgraph/blob/master/janusgraph-core/src/main/java/org/janusgraph/core/attribute/Geoshape.java#L542).
In 0.1.x Geoshape serialization was en tab of float, in 0.2.0 JanusGraph use JtsBinaryCodec. So a geoshape serializes in 0.1.x can not be read by 0.2.0. 

What do you think ?

I did not know if there are any other breaking change.

David

--
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.



--
There is no place like /home.


Re: Not able to 'addEdge' to 'CacheVertex'

Teena K <avidlea...@...>
 

    
    JanusGraph graph = JanusGraphFactory.open("<path>/janusgraph/conf/janusgraph-cassandra.properties");
    JanusGraphTransaction tx = graph.newTransaction();    
    GraphTraversalSource g = graph.traversal();

    <code to add vertices and edges>

    tx.commit();

    The transaction is committed after all the code is executed.


On Thursday, June 29, 2017 at 10:04:20 PM UTC+5:30, Jason Plurad wrote:
You've left out some context here. How are g` and `tx` initialized? Where is the transaction committed?

On Thursday, June 29, 2017 at 10:33:49 AM UTC-4, Teena K wrote:


down votefavorite

I have the below code in my java program that queries janusgraph to create vertices and edges if they don't exist already.

Vertex v1 = g.V().has(<key1>,<value1>).tryNext().orElseGet(()->
tx.addVertex(T.label,<label1>,<key1>,<value1>));
Vertex v2 = g.V().has(<key2>,<value2>).tryNext().orElseGet(()->
tx.addVertex(T.label,<label2>,<key2>,<value2>));

Vertices v1 and v2 get created if they don't exist.

..code to check if an edge exists between the two vertices..
..if there is no edge between the two, create an edge
v1.addEdge(<label3>,v2,<key3>,<value3>)

If the vertices are newly created, the code works fine and the edge also gets created between the two vertices. But if the vertices already exist in the DB, the edge doesn't get created. The difference I could find between the two cases is that v1 and v2 are of 'StandardVertex' type when they are newly created and they are of 'CacheVertex' type when they already exist. 'addEdge' is a valid method in both cases. Yet the edge doesn't get created.


Re: [DISCUSS] Splitting janusgraph-cassandra

sjudeng <sju...@...>
 

Samant, It's been 5 days and no one has yelled too loud so I think it's reasonable to move forward with your PR on this if you're still up for it.

Ted, I don't think the reorganization here would cause any additional complexities with the eventual deprecation of Thrift. On the surface it seems to me it might make it simpler to carry out the deprecation/removal if the Thrift components are separated into a standalone module like here.


On Friday, June 23, 2017 at 10:45:50 PM UTC-5, sjudeng wrote:
All,

Samant has said he should be able to continue working on this effort. The current proposal is to refactor into the following structure.

├─ janusgraph-cassandra-parent/
│   ├── astyanax
│   ├── cql
│   ├── core
│   ├── embedded
│   ├── test
│   ├── thrift

+1 for me. I think it's a step in the right direction and I'd hate to see the work already done on this go to waste.

Jason, is this something that needs a separate vote thread or can the work/PR just move forward?

Samant, What do you think about Ted's question above?


On Saturday, June 17, 2017 at 12:28:41 PM UTC-5, sjudeng wrote:
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: Potential breaking changes in 0.2.0

sjudeng <sju...@...>
 

Although it's not as clean I think it's worth pursing the configuration option. You could call it something obtrusive like "index.elasicsearch.use-deprecated-multitype-index". If possible I think we'd want it to default to false so all new indices are split, but be treated as true if not present as in the case for legacy indices. As far as implementation complexity, would it maybe be as simple as adding logic to your ElasticSearchIndex.getIndexStoreName() method? Regarding your desired index deletion work, could you move forward if support is limited to single-type indices (e.g. so there'd be an additional conditional at https://github.com/JanusGraph/janusgraph/blob/bfa3c970555932d4983155168322f72297aaee85/janusgraph-core/src/main/java/org/janusgraph/graphdb/olap/job/IndexRemoveJob.java#L104)?

I'd still like to hear from others as well but this is what I'm thinking.


On Wednesday, June 28, 2017 at 11:47:49 AM UTC-5, Davide Bolcioni wrote:
I would expect an incompatible change to bump the major version, so 1.*

On Wed, Jun 28, 2017 at 9:00 AM, david.clement90 via JanusGraph developer list <janusgr...@googlegroups.com> wrote:
I add this thread to discuss about breaking change in 0.2.0 with this PR https://github.com/JanusGraph/janusgraph/pull/336.

This PR add a breaking change for Elasticsearch backend because it Elasticsearch split index into N indexes.
To deals with this, we have three options :
  1.  0.2.0 is not compatible with 0.1.x
  2. We create a script to migrate index.
  3. We make the configuration switch.

But, for me 0.2.0 is already not compatible with 0.1.x because Geoshape serialization (https://github.com/JanusGraph/janusgraph/blob/master/janusgraph-core/src/main/java/org/janusgraph/core/attribute/Geoshape.java#L542).
In 0.1.x Geoshape serialization was en tab of float, in 0.2.0 JanusGraph use JtsBinaryCodec. So a geoshape serializes in 0.1.x can not be read by 0.2.0. 

What do you think ?

I did not know if there are any other breaking change.

David

--
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.



--
There is no place like /home.


Re: Not able to 'addEdge' to 'CacheVertex'

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

You've left out some context here. How are g` and `tx` initialized? Where is the transaction committed?

On Thursday, June 29, 2017 at 10:33:49 AM UTC-4, Teena K wrote:


down votefavorite

I have the below code in my java program that queries janusgraph to create vertices and edges if they don't exist already.

Vertex v1 = g.V().has(<key1>,<value1>).tryNext().orElseGet(()->
tx.addVertex(T.label,<label1>,<key1>,<value1>));
Vertex v2 = g.V().has(<key2>,<value2>).tryNext().orElseGet(()->
tx.addVertex(T.label,<label2>,<key2>,<value2>));

Vertices v1 and v2 get created if they don't exist.

..code to check if an edge exists between the two vertices..
..if there is no edge between the two, create an edge
v1.addEdge(<label3>,v2,<key3>,<value3>)

If the vertices are newly created, the code works fine and the edge also gets created between the two vertices. But if the vertices already exist in the DB, the edge doesn't get created. The difference I could find between the two cases is that v1 and v2 are of 'StandardVertex' type when they are newly created and they are of 'CacheVertex' type when they already exist. 'addEdge' is a valid method in both cases. Yet the edge doesn't get created.


Not able to 'addEdge' to 'CacheVertex'

Teena K <avidlea...@...>
 


I have the below code in my java program that queries janusgraph to create vertices and edges if they don't exist already.

Vertex v1 = g.V().has(<key1>,<value1>).tryNext().orElseGet(()->
tx.addVertex(T.label,<label1>,<key1>,<value1>));
Vertex v2 = g.V().has(<key2>,<value2>).tryNext().orElseGet(()->
tx.addVertex(T.label,<label2>,<key2>,<value2>));

Vertices v1 and v2 get created if they don't exist.

..code to check if an edge exists between the two vertices..
..if there is no edge between the two, create an edge
v1.addEdge(<label3>,v2,<key3>,<value3>)

If the vertices are newly created, the code works fine and the edge also gets created between the two vertices. But if the vertices already exist in the DB, the edge doesn't get created. The difference I could find between the two cases is that v1 and v2 are of 'StandardVertex' type when they are newly created and they are of 'CacheVertex' type when they already exist. 'addEdge' is a valid method in both cases. Yet the edge doesn't get created.


Re: Potential breaking changes in 0.2.0

Davide Bolcioni <dbol...@...>
 

I would expect an incompatible change to bump the major version, so 1.*

On Wed, Jun 28, 2017 at 9:00 AM, david.clement90 via JanusGraph developer list <janusgr...@...> wrote:
I add this thread to discuss about breaking change in 0.2.0 with this PR https://github.com/JanusGraph/janusgraph/pull/336.

This PR add a breaking change for Elasticsearch backend because it Elasticsearch split index into N indexes.
To deals with this, we have three options :
  1.  0.2.0 is not compatible with 0.1.x
  2. We create a script to migrate index.
  3. We make the configuration switch.

But, for me 0.2.0 is already not compatible with 0.1.x because Geoshape serialization (https://github.com/JanusGraph/janusgraph/blob/master/janusgraph-core/src/main/java/org/janusgraph/core/attribute/Geoshape.java#L542).
In 0.1.x Geoshape serialization was en tab of float, in 0.2.0 JanusGraph use JtsBinaryCodec. So a geoshape serializes in 0.1.x can not be read by 0.2.0. 

What do you think ?

I did not know if there are any other breaking change.

David

--
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.



--
There is no place like /home.


Potential breaking changes in 0.2.0

david.c...@...
 

I add this thread to discuss about breaking change in 0.2.0 with this PR https://github.com/JanusGraph/janusgraph/pull/336.

This PR add a breaking change for Elasticsearch backend because it Elasticsearch split index into N indexes.
To deals with this, we have three options :
  1.  0.2.0 is not compatible with 0.1.x
  2. We create a script to migrate index.
  3. We make the configuration switch.
Between 2 and 3, I prefer 2 because I would like to add a delete method by index to solve https://github.com/JanusGraph/janusgraph/issues/354 and to remove this https://github.com/JanusGraph/janusgraph/blob/master/janusgraph-core/src/main/java/org/janusgraph/graphdb/olap/job/IndexRemoveJob.java#L105

But, for me 0.2.0 is already not compatible with 0.1.x because Geoshape serialization (https://github.com/JanusGraph/janusgraph/blob/master/janusgraph-core/src/main/java/org/janusgraph/core/attribute/Geoshape.java#L542).
In 0.1.x Geoshape serialization was en tab of float, in 0.2.0 JanusGraph use JtsBinaryCodec. So a geoshape serializes in 0.1.x can not be read by 0.2.0. 

What do you think ?

I did not know if there are any other breaking change.

David


Re: 0.2.0-SNAPSHOT updates?

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

Hey Jason,
I think you should be good to go since you added your name to the list on this issue: https://github.com/janusgraph/janusgraph/issues/97. With Sonatype permissions you'll be able to deploy the snapshot. Since that doesn't include binaries at this point, I've used the GitHub release feature to upload snapshot binaries before.  If you try it out and run into any issues, let me know.

--Ted

On Monday, June 26, 2017 at 8:42:20 PM UTC-5, Jason Plurad wrote:
Thanks, Ted. Are there other committers that have authority to publish a snapshot? I'd be happy to be added to the list of publishers if we had a writeup on how to do it.

-- Jason

On Friday, June 23, 2017 at 12:38:58 PM UTC-4, Ted Wilmes wrote:
Hello,
We'll probably start working on a release candidate for 0.2.0 shortly so I'll get another snapshot published before that, and yes, agreed on the automation! That's something that we need to get in place.

--Ted

On Thursday, June 22, 2017 at 8:10:09 AM UTC-5, wojcik.w wrote:
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: 0.2.0-SNAPSHOT updates?

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

Thanks, Ted. Are there other committers that have authority to publish a snapshot? I'd be happy to be added to the list of publishers if we had a writeup on how to do it.

-- Jason


On Friday, June 23, 2017 at 12:38:58 PM UTC-4, Ted Wilmes wrote:
Hello,
We'll probably start working on a release candidate for 0.2.0 shortly so I'll get another snapshot published before that, and yes, agreed on the automation! That's something that we need to get in place.

--Ted

On Thursday, June 22, 2017 at 8:10:09 AM UTC-5, wojcik.w wrote:
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 :)

1281 - 1300 of 1589