Re: Code Freeze 3.1.4/3.2.2

[Ted Wilmes]

Cool, thanks for the update.  I had not merged tp31 back into master after
my changelog updates so thanks for taking care of that.

--Ted

On Thu, Sep 1, 2016 at 12:54 PM, Stephen Mallette 
wrote:

> Ted, I noticed some formatting problems in the headers for asciidoc on the
> tp31 branch. I corrected those. I don't think you need to republish the
> SNAPSHOT docs over that minor change. Obviously, we'd get the fixes in the
> official release.  I also implemented this on tp31:
>
> https://issues.apache.org/jira/browse/TINKERPOP-1416
>
> I updated CHANGELOG manually since you already generated that stuff.
>
>
>
> On Wed, Aug 31, 2016 at 3:00 PM, Ted Wilmes  wrote:
>
> > The 3.1.4-SNAPSHOT docs have been published to: http://tinkerpop.apache.
> > org/docs/3.1.4-SNAPSHOT/
> >
> > Changelog bugs and improvements have also been updated with where we
> stand
> > at this point with 3.1.4:
> > https://github.com/apache/tinkerpop/blob/tp31/CHANGELOG.asciidoc
> >
> > Thanks,
> > Ted
> >
> >
> >
> >
> > On Sun, Aug 28, 2016 at 7:52 AM, Ted Wilmes  wrote:
> >
> > > Hello,
> > > The 3.1.4-SNAPSHOT has been published.  As Stephen mentioned, we do not
> > > expect any
> > > non-doc changes/additions to tp31 but let me know if something comes
> up.
> > > I'll be reviewing
> > > the docs and publishing a doc snapshot later this week.
> > >
> > > Thanks,
> > > Ted
> > >
> > > On Sat, Aug 27, 2016 at 5:15 AM, Stephen Mallette <
> spmalle...@gmail.com>
> > > wrote:
> > >
> > >> Code freeze begins today. Some minor changes to expect on master:
> > >>
> > >> + We have one lingering PR that needs to be merged once it is rebased:
> > >> https://github.com/apache/tinkerpop/pull/385
> > >> + I suspect we will see more tests on gremlin-python as well as tweaks
> > to
> > >> the build process
> > >> + We may see one more serializers added to GraphSON 2.0 -
> > >> TraversalExplanation
> > >> + More docs as usual
> > >>
> > >> Recall, that gremlin-python and GraphSON 2.0 will be "experimental"
> so I
> > >> don't think we should be too concerned about late changes on that
> stuff
> > at
> > >> this point. So - nothing major coming down the pike and as far as I
> know
> > >> there shouldn't be any change on tp31 branch aside from some added
> > >> documentation.
> > >>
> > >> Providers should be free to test things out in their implementations.
> > I've
> > >> published the 3.2.2-SNAPSHOT to Apache Snapshots repo. Note that Ted
> is
> > >> going to be handling the 3.1.4 release - he will publish the
> > >> 3.1.4-SNAPSHOT
> > >> sometime soon (thanks for helping out with that Ted - it will be
> > >> interesting to have two voices taking us through code freeze week into
> > >> release)..
> > >>
> > >> As usual, please stay tuned to this thread for updates as we head to
> > >> release. Thanks!
> > >>
> > >
> > >
> >
>

[DISCUSS] Rename REST references to HTTP

[Stephen Mallette]

Robert Dale brought this issue up:

https://issues.apache.org/jira/browse/TINKERPOP-1369

Basically - "The "REST API" follows exactly none of the tenets of being
RESTful. Suggest renaming it to HTTP API so as to not mislead developers as
to the design of the API."

I agree with the technical assessment, but I don't know that the average
developer will make such distinctions as easily. People will begin
wondering where "REST" went and the questions will follow.  Anyway, that's
my main reluctance with this ticket.  if the consensus here is to make the
naming more technically correct, then we can leave the issue open for a
change in 3.3.0, otherwise I'd like to close and get another JIRA issue off
the board. :).

Anyone feel strongly about this issue one way or the other?

[jira] [Updated] (TINKERPOP-927) bin/publish-docs.sh should only upload diffs.

[stephen mallette (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stephen mallette updated TINKERPOP-927:
---
Component/s: (was: documentation)
 build-release

> bin/publish-docs.sh should only upload diffs.
> -
>
> Key: TINKERPOP-927
> URL: https://issues.apache.org/jira/browse/TINKERPOP-927
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: build-release
>Affects Versions: 3.0.2-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Daniel Kuppitz
>
> It takes forever for us to publish-docs. Can we just do a "diff" and see what 
> changed (MD5?) and then {{svn up}} only those files?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (TINKERPOP-986) Manage binary LICENSE/NOTICE files with bin/checkLicenseNotice.sh

[stephen mallette (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stephen mallette closed TINKERPOP-986.
--
Resolution: Won't Fix
  Assignee: stephen mallette  (was: Daniel Kuppitz)

[~dkuppitz] I think I'm going to just close this. It's been less hard than I 
thought to keep track of the changes to these files as dependencies don't 
change too often and when they do, it's relatively easy to manually review 
what's changed. As long as we keep to our review process when it comes to this 
kind of stuff, I don't think we need to spend time on developing automation 
that might not even completely eliminate the manual work.

> Manage binary LICENSE/NOTICE files with bin/checkLicenseNotice.sh
> -
>
> Key: TINKERPOP-986
> URL: https://issues.apache.org/jira/browse/TINKERPOP-986
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: build-release
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>
> Provide a script to help manage binary LICENSE/NOTICE files.  Basically need 
> to:
> 1. know if the dependencies we bundled in the zips changed since a previous 
> version
> 2. extract LICENSE/NOTICE files from the bundled jars
> it would work something like this:
> {code}
> bin/checkLicenseNotice.sh current.zip previous.zip
> {code}
> The result would be in a directory at {{target/checkLicenseNotice}}.  The 
> result would consist of 
> 1. {{target/checkLicenseNotice/previous}} - a list of LICENSE/NOTICE files 
> from "previous.zip" as extracted from the jar files in the distribution.  
> "TinkerPop" jars can be ignored.
> 2. {{target/checkLicenseNotice/current}} - a list of LICENSE/NOTICE files 
> from "current.zip" as extracted from the jar files in the distribution.  
> "TinkerPop" jars can be ignored.
> 3. {{target/checkLicenseNotice/diff}}- a list of LICENSE/NOTICE files that 
> are "new" or "removed" (we'll ignore "changed" for the moment i guess unless 
> an easy way to present that is determined) as determined by a compare between 
> "previous" and "current"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TINKERPOP-1427) GraphSON 2.0 needs collection types and consistent number typing.

[Marko A. Rodriguez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marko A. Rodriguez updated TINKERPOP-1427:
--
Labels: breaking  (was: )

> GraphSON 2.0 needs collection types and consistent number typing.
> -
>
> Key: TINKERPOP-1427
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1427
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.2.1
>Reporter: Marko A. Rodriguez
>  Labels: breaking
>
> Before 3.3.0, we need to get the story around collections straight. Currently 
> we are relying on JSON collections to represent our collections, but this 
> isn't always sound -- e.g. JSON maps can only have string keys.
> Thus, we need:
> {code}
> g:Map
> g:List
> g:Set
> {code}
> Note that all of these would just be JSON lists:
> {code}
> {@type:"g:Map", @value:[key1,value1,key2,value2,key3,value3,...]}
> {@type:"g:List", @value:[value1, value2, value3,...]}
> {@type:"g:Set", @value:[value1, value2, value3,...]}
> {code}
> ---
> Next, these data structures are exactly what play into {{aggregateTo}} in 
> sideEffects for {{RemoteConnection}}. Thus, we should use these types and, as 
> well, get rid of {{none}} as the aggregate would be a real type like 
> {{g:Int32}}.
> Also, I think we should abandon this hybrid physical machine naming 
> convention and programming language type convention.
> {code}
> g:Int32 -> g:Integer
> g:Int64 -> g:Long
> g:Double -> g:Double (no change)
> g:Float -> g:Float (no change)
> {code}
> If we want to be consistent either do the above or do the below, though I 
> think the above is cleaner.
> {code}
> g:Int32 -> g:Int32
> g:Int64 -> g:Int64
> g:Float -> g:Float32
> g:Double -> g:Float64
> {code}
> Again, using programming lexicon vs. physical machine lexicon is best and 
> thus, just gut "int32" and "int64."



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TINKERPOP-1427) GraphSON 2.0 needs collection types and consistent number typing.

[Marko A. Rodriguez (JIRA)]

Marko A. Rodriguez created TINKERPOP-1427:
-

 Summary: GraphSON 2.0 needs collection types and consistent number 
typing.
 Key: TINKERPOP-1427
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1427
 Project: TinkerPop
  Issue Type: Improvement
  Components: io
Affects Versions: 3.2.1
Reporter: Marko A. Rodriguez


Before 3.3.0, we need to get the story around collections straight. Currently 
we are relying on JSON collections to represent our collections, but this isn't 
always sound -- e.g. JSON maps can only have string keys.

Thus, we need:

{code}
g:Map
g:List
g:Set
{code}

Note that all of these would just be JSON lists:

{code}
{@type:"g:Map", @value:[key1,value1,key2,value2,key3,value3,...]}
{@type:"g:List", @value:[value1, value2, value3,...]}
{@type:"g:Set", @value:[value1, value2, value3,...]}
{code}

---

Next, these data structures are exactly what play into {{aggregateTo}} in 
sideEffects for {{RemoteConnection}}. Thus, we should use these types and, as 
well, get rid of {{none}} as the aggregate would be a real type like 
{{g:Int32}}.

Also, I think we should abandon this hybrid physical machine naming convention 
and programming language type convention.

{code}
g:Int32 -> g:Integer
g:Int64 -> g:Long
g:Double -> g:Double (no change)
g:Float -> g:Float (no change)
{code}

If we want to be consistent either do the above or do the below, though I think 
the above is cleaner.

{code}
g:Int32 -> g:Int32
g:Int64 -> g:Int64
g:Float -> g:Float32
g:Double -> g:Float64
{code}

Again, using programming lexicon vs. physical machine lexicon is best and thus, 
just gut "int32" and "int64."





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Code Freeze 3.1.4/3.2.2

[Stephen Mallette]

Ted, I noticed some formatting problems in the headers for asciidoc on the
tp31 branch. I corrected those. I don't think you need to republish the
SNAPSHOT docs over that minor change. Obviously, we'd get the fixes in the
official release.  I also implemented this on tp31:

https://issues.apache.org/jira/browse/TINKERPOP-1416

I updated CHANGELOG manually since you already generated that stuff.



On Wed, Aug 31, 2016 at 3:00 PM, Ted Wilmes  wrote:

> The 3.1.4-SNAPSHOT docs have been published to: http://tinkerpop.apache.
> org/docs/3.1.4-SNAPSHOT/
>
> Changelog bugs and improvements have also been updated with where we stand
> at this point with 3.1.4:
> https://github.com/apache/tinkerpop/blob/tp31/CHANGELOG.asciidoc
>
> Thanks,
> Ted
>
>
>
>
> On Sun, Aug 28, 2016 at 7:52 AM, Ted Wilmes  wrote:
>
> > Hello,
> > The 3.1.4-SNAPSHOT has been published.  As Stephen mentioned, we do not
> > expect any
> > non-doc changes/additions to tp31 but let me know if something comes up.
> > I'll be reviewing
> > the docs and publishing a doc snapshot later this week.
> >
> > Thanks,
> > Ted
> >
> > On Sat, Aug 27, 2016 at 5:15 AM, Stephen Mallette 
> > wrote:
> >
> >> Code freeze begins today. Some minor changes to expect on master:
> >>
> >> + We have one lingering PR that needs to be merged once it is rebased:
> >> https://github.com/apache/tinkerpop/pull/385
> >> + I suspect we will see more tests on gremlin-python as well as tweaks
> to
> >> the build process
> >> + We may see one more serializers added to GraphSON 2.0 -
> >> TraversalExplanation
> >> + More docs as usual
> >>
> >> Recall, that gremlin-python and GraphSON 2.0 will be "experimental" so I
> >> don't think we should be too concerned about late changes on that stuff
> at
> >> this point. So - nothing major coming down the pike and as far as I know
> >> there shouldn't be any change on tp31 branch aside from some added
> >> documentation.
> >>
> >> Providers should be free to test things out in their implementations.
> I've
> >> published the 3.2.2-SNAPSHOT to Apache Snapshots repo. Note that Ted is
> >> going to be handling the 3.1.4 release - he will publish the
> >> 3.1.4-SNAPSHOT
> >> sometime soon (thanks for helping out with that Ted - it will be
> >> interesting to have two voices taking us through code freeze week into
> >> release)..
> >>
> >> As usual, please stay tuned to this thread for updates as we head to
> >> release. Thanks!
> >>
> >
> >
>

[jira] [Closed] (TINKERPOP-1416) Write Gremlin Server log files somewhere during doc generation

[stephen mallette (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stephen mallette closed TINKERPOP-1416.
---
   Resolution: Done
 Assignee: stephen mallette
Fix Version/s: 3.2.2
   3.1.4

> Write Gremlin Server log files somewhere during doc generation
> --
>
> Key: TINKERPOP-1416
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1416
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: build-release
>Affects Versions: 3.1.3
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.1.4, 3.2.2
>
>
> Would be nice if we didn't lose gremlin server log files during 
> process-docs.sh. They can be helpful when debugging stuff that's gone wrong. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1416) Write Gremlin Server log files somewhere during doc generation

[stephen mallette (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15456137#comment-15456137
 ] 

stephen mallette commented on TINKERPOP-1416:
-

Fixed via CTR with: 
https://github.com/apache/tinkerpop/commit/09e842714856996ca5f1335f2037b79a58b0f928

> Write Gremlin Server log files somewhere during doc generation
> --
>
> Key: TINKERPOP-1416
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1416
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: build-release
>Affects Versions: 3.1.3
>Reporter: stephen mallette
>
> Would be nice if we didn't lose gremlin server log files during 
> process-docs.sh. They can be helpful when debugging stuff that's gone wrong. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1230) Serialising lambdas for RemoteGraph

[Michael Pollmeier (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15455906#comment-15455906
 ] 

Michael Pollmeier commented on TINKERPOP-1230:
--

Thanks for your thoughts Stephen. Dropping additional libs into DSE sounds 
doable yet dangerous. If I did so, would I be able to call my code though? 
I'd need some plugin system, e.g. to define an endpoint that's being exposed 
that then calls my code. If I read the OpProcessor interface right then this 
could do it for websocket? Is there a similar way for http? 

> Serialising lambdas for RemoteGraph
> ---
>
> Key: TINKERPOP-1230
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1230
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: driver, server
>Affects Versions: 3.1.1-incubating
>Reporter: Michael Pollmeier
>Assignee: Marko A. Rodriguez
>Priority: Minor
> Fix For: 3.2.2
>
>
> I just made an attempt to serialise lambdas and send them via the 
> RemoteGraph. I didn't quite get there, but wanted to share my findings: 
> * it's possible to serialise lambdas on the jvm by just extending 
> `Serializable`:
> http://stackoverflow.com/questions/22807912/how-to-serialize-a-lambda/22808112#22808112
> * sending a normal predicate doesn't work (this is a Scala REPL but it should 
> be pretty easy to convert this to java/groovy)
>   val g = RemoteGraph.open("conf/remote-graph.properties").traversal()
>   val pred1 = new java.util.function.Predicate[Traverser[Vertex]] { def 
> test(v: Traverser[Vertex]) = true }
>   g.V().filter(pred1).toList 
> // java.lang.RuntimeException: java.io.NotSerializableException: $anon$1
>  // on server: nothing
>  
> * simply adding Serializable let's us send it over the wire, but the server 
> doesn't deserialise it
>   val pred2 = new java.util.function.Predicate[Traverser[Vertex]] with 
> Serializable { def test(v: Traverser[Vertex]) = true }
>   g.V().filter(pred2).toList 
>   // on server: [WARN] OpExecutorHandler - Could not deserialize the 
> Traversal instance
> org.apache.tinkerpop.gremlin.server.op.OpProcessorException: Could 
> not deserialize the Traversal instance
> at 
> org.apache.tinkerpop.gremlin.server.op.traversal.TraversalOpProcessor.iterateOp(TraversalOpProcessor.java:135)
> at 
> org.apache.tinkerpop.gremlin.server.handler.OpExecutorHandler.channelRead0(OpExecutorHandler.java:68)
>   // on client: 
> org.apache.tinkerpop.gremlin.driver.exception.ResponseException: $anon$1 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: permission request to use character scene graphics

[Marko Rodriguez]

Its TinkerPop related so this is “okay” by me. If there are no objections, 
please feel to use the image publicly in 72 hours.

Thanks,
Marko.

http://markorodriguez .com


> On Sep 1, 2016, at 9:51 AM, Jason Plurad  wrote:
> 
> Hi,
> 
> I'm drafting a blog post about Apache TinkerPop and several TinkerPop
> providers, and I'd like to use this cool image in the post. I'll touch on
> TinkerPop's graduation and other news/releases from this summer.
> 
> https://raw.githubusercontent.com/apache/tinkerpop/3.2.1/docs/static/images/gremlin-dashboard.png
> 
> Please let me know if it would be ok. Thanks.
> 
> -- Jason

[jira] [Resolved] (TINKERPOP-1383) publish-docs.sh might publish to current too early

[Daniel Kuppitz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel Kuppitz resolved TINKERPOP-1383.
---
Resolution: Fixed

> publish-docs.sh might publish to current too early
> --
>
> Key: TINKERPOP-1383
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1383
> Project: TinkerPop
>  Issue Type: Bug
>  Components: build-release
>Affects Versions: 3.1.3
>Reporter: stephen mallette
>Assignee: Daniel Kuppitz
> Fix For: 3.2.2
>
>
> In the standard release flow of things, the release manager runs 
> `bin/publish-docs.sh` right before VOTE which means that `/current` gets 
> updated at least 3 days before we announce the release. 
> Maybe updating current should be a specific command? 
> {code}
> bin/publish-docs.sh --update userName
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (TINKERPOP-1383) publish-docs.sh might publish to current too early

[Daniel Kuppitz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel Kuppitz closed TINKERPOP-1383.
-

> publish-docs.sh might publish to current too early
> --
>
> Key: TINKERPOP-1383
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1383
> Project: TinkerPop
>  Issue Type: Bug
>  Components: build-release
>Affects Versions: 3.1.3
>Reporter: stephen mallette
>Assignee: Daniel Kuppitz
> Fix For: 3.2.2
>
>
> In the standard release flow of things, the release manager runs 
> `bin/publish-docs.sh` right before VOTE which means that `/current` gets 
> updated at least 3 days before we announce the release. 
> Maybe updating current should be a specific command? 
> {code}
> bin/publish-docs.sh --update userName
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1383) publish-docs.sh might publish to current too early

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15455762#comment-15455762
 ] 

ASF GitHub Bot commented on TINKERPOP-1383:
---

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/396
  
CTR'ed.


> publish-docs.sh might publish to current too early
> --
>
> Key: TINKERPOP-1383
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1383
> Project: TinkerPop
>  Issue Type: Bug
>  Components: build-release
>Affects Versions: 3.1.3
>Reporter: stephen mallette
>Assignee: Daniel Kuppitz
> Fix For: 3.2.2
>
>
> In the standard release flow of things, the release manager runs 
> `bin/publish-docs.sh` right before VOTE which means that `/current` gets 
> updated at least 3 days before we announce the release. 
> Maybe updating current should be a specific command? 
> {code}
> bin/publish-docs.sh --update userName
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1383) publish-docs.sh might publish to current too early

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15455761#comment-15455761
 ] 

ASF GitHub Bot commented on TINKERPOP-1383:
---

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/396


> publish-docs.sh might publish to current too early
> --
>
> Key: TINKERPOP-1383
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1383
> Project: TinkerPop
>  Issue Type: Bug
>  Components: build-release
>Affects Versions: 3.1.3
>Reporter: stephen mallette
>Assignee: Daniel Kuppitz
> Fix For: 3.2.2
>
>
> In the standard release flow of things, the release manager runs 
> `bin/publish-docs.sh` right before VOTE which means that `/current` gets 
> updated at least 3 days before we announce the release. 
> Maybe updating current should be a specific command? 
> {code}
> bin/publish-docs.sh --update userName
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop issue #396: TINKERPOP-1383 publish-docs.sh might publish to curren...

[dkuppitz]

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/396
  
CTR'ed.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1426) GryoSerializer should implement Java serialization interface

[Marko A. Rodriguez (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15455734#comment-15455734
 ] 

Marko A. Rodriguez commented on TINKERPOP-1426:
---

If you can get Spark 2.0 working, that would be huge. Perhaps create one PR 
that is both this ticket as well as TINKERPOP-1389. Note that I will be 
traveling next week so I might not be able to review immediately, but will 
definately try my best  to get your feedback ASAP. Thank you for your efforts.

> GryoSerializer should implement Java serialization interface
> 
>
> Key: TINKERPOP-1426
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1426
> Project: TinkerPop
>  Issue Type: Bug
>  Components: io
>Affects Versions: 3.2.1
>Reporter: Chen Xin Yu
>
> There is description for Serializer in spark:
>  * Implementations of this trait should implement:
>  *
>  * 1. a zero-arg constructor or a constructor that accepts a 
> [[org.apache.spark.SparkConf]]
>  * as parameter. If both constructors are defined, the latter takes 
> precedence.
>  *
>  * 2. Java serialization interface.
> Class GryoSerializer in Tinkerepop extends Serializer, but does not implement 
> java.io.Serializable. 
> It works well before Spark 2.0. But with Spark 2.0, it changed by SPARK-13926 
> for Dependency,scala. 
> Gyro and all its fields must implement Java serialisation interface, 
> otherwise hundreds of test cases are failed as:
> Caused by: org.apache.spark.SparkException: Job aborted due to stage failure: 
> Task not serializable: java.io.NotSerializableException: 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.GryoSerializer
> Serialization stack:
>   - object not serializable (class: 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.GryoSerializer, value: 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.GryoSerializer@1b12ec8e)
>   - field (class: org.apache.spark.ShuffleDependency, name: serializer, 
> type: class org.apache.spark.serializer.Serializer)
>   - object (class org.apache.spark.ShuffleDependency, 
> org.apache.spark.ShuffleDependency@7a4f876a)
>   - field (class: scala.Tuple2, name: _2, type: class java.lang.Object)
>   - object (class scala.Tuple2, (MapPartitionsRDD[1] at mapToPair at 
> InputFormatRDD.java:46,org.apache.spark.ShuffleDependency@7a4f876a))



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1426) GryoSerializer should implement Java serialization interface

[Chen Xin Yu (JIRA)]

[ 
https://issues.apache.org/jira/browse/TINKERPOP-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15455720#comment-15455720
 ] 

Chen Xin Yu commented on TINKERPOP-1426:


I have a draft fix for this JIRA, I will try to submit a pull request on github.

> GryoSerializer should implement Java serialization interface
> 
>
> Key: TINKERPOP-1426
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1426
> Project: TinkerPop
>  Issue Type: Bug
>  Components: io
>Affects Versions: 3.2.1
>Reporter: Chen Xin Yu
>
> There is description for Serializer in spark:
>  * Implementations of this trait should implement:
>  *
>  * 1. a zero-arg constructor or a constructor that accepts a 
> [[org.apache.spark.SparkConf]]
>  * as parameter. If both constructors are defined, the latter takes 
> precedence.
>  *
>  * 2. Java serialization interface.
> Class GryoSerializer in Tinkerepop extends Serializer, but does not implement 
> java.io.Serializable. 
> It works well before Spark 2.0. But with Spark 2.0, it changed by SPARK-13926 
> for Dependency,scala. 
> Gyro and all its fields must implement Java serialisation interface, 
> otherwise hundreds of test cases are failed as:
> Caused by: org.apache.spark.SparkException: Job aborted due to stage failure: 
> Task not serializable: java.io.NotSerializableException: 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.GryoSerializer
> Serialization stack:
>   - object not serializable (class: 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.GryoSerializer, value: 
> org.apache.tinkerpop.gremlin.spark.structure.io.gryo.GryoSerializer@1b12ec8e)
>   - field (class: org.apache.spark.ShuffleDependency, name: serializer, 
> type: class org.apache.spark.serializer.Serializer)
>   - object (class org.apache.spark.ShuffleDependency, 
> org.apache.spark.ShuffleDependency@7a4f876a)
>   - field (class: scala.Tuple2, name: _2, type: class java.lang.Object)
>   - object (class scala.Tuple2, (MapPartitionsRDD[1] at mapToPair at 
> InputFormatRDD.java:46,org.apache.spark.ShuffleDependency@7a4f876a))



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TINKERPOP-1383) publish-docs.sh might publish to current too early

[stephen mallette (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stephen mallette updated TINKERPOP-1383:

Fix Version/s: (was: 3.1.4)

Removed as a requirement to fix from the 3.1.x line because this line will 
never trigger the update of "current".

> publish-docs.sh might publish to current too early
> --
>
> Key: TINKERPOP-1383
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1383
> Project: TinkerPop
>  Issue Type: Bug
>  Components: build-release
>Affects Versions: 3.1.3
>Reporter: stephen mallette
>Assignee: Daniel Kuppitz
> Fix For: 3.2.2
>
>
> In the standard release flow of things, the release manager runs 
> `bin/publish-docs.sh` right before VOTE which means that `/current` gets 
> updated at least 3 days before we announce the release. 
> Maybe updating current should be a specific command? 
> {code}
> bin/publish-docs.sh --update userName
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: New Committer: David Brown

[Mark Henderson]

This is great news. I use your connection library for Python all the time. 
Will your libs like Gremlinclient/Goblin be apart of/influence what is 
being done with Gremlin Server?

On Wednesday, August 31, 2016 at 6:45:49 PM UTC-4, David Brown wrote:
>
> Thanks everyone! I am really looking forward to contributing. 
>
> On Wed, Aug 31, 2016 at 1:09 PM, Kelvin Lawrence 
>  wrote: 
> > Congratulations David - I see a lot of folks very excited about the 
> prospect 
> > of combining Python and Gremlin! 
> > 
> > Kelvin 
> > 
> > 
> > On Wednesday, August 31, 2016 at 10:10:53 AM UTC-5, Stephen Mallette 
> wrote: 
> >> 
> >> The Project Management Committee (PMC) for Apache TinkerPop has asked 
> >> David Brown to become a committer and we are pleased to announce that 
> he has 
> >> accepted. 
> >> 
> >> If you're using TinkerPop with Python today, it's likely because of 
> David 
> >> Brown's work. He was the first person to implement the Gremlin Server 
> >> protocol for TinkerPop 3.x outside of my initial implementation. He 
> built 
> >> many other Python related libraries for TinkerPop since then, provided 
> >> testing during releases and added a good bit of input on Gremlin Server 
> >> along the way. 
> >> 
> >> Being a committer enables easier contribution to the project since 
> there 
> >> is no need to work via the patch submission process. This should enable 
> >> better productivity. 
> >> 
> >> 
> > 
>
>
>
> -- 
> David M. Brown 
> R.A. CulturePlex Lab, Western University 
>

[GitHub] tinkerpop pull request #:

[spmallette]

Github user spmallette commented on the pull request:


https://github.com/apache/tinkerpop/commit/fbde4e2ae67b52ad56b4c33f8b3c7eb56a1a5fea#commitcomment-18861935
  
In gremlin-benchmark/pom.xml:
In gremlin-benchmark/pom.xml on line 73:
i had it that way, but then i noticed that there's no tests in 
gremlin-benchmark. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] tinkerpop pull request #:

[analytically]

Github user analytically commented on the pull request:


https://github.com/apache/tinkerpop/commit/fbde4e2ae67b52ad56b4c33f8b3c7eb56a1a5fea#commitcomment-18861765
  
In gremlin-benchmark/pom.xml:
In gremlin-benchmark/pom.xml on line 73:
test?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---