code freeze 3.2.5

[Stephen Mallette]

Just a reminder that code is frozen on the tp32 branch starting tomorrow
(Saturday) and for the following week. We'll use this thread to discuss any
issues or problems on 3.2.5 that are found during testing. There are no
open pull requests and no outstanding issues that I'm aware of. I've
published a TinkerPop 3.2.5-SNAPSHOT for providers to test against (or they
may build themselves - whatever is more convenient).

Thanks,

Stephen

Modern Graph

[Stephen Mallette]

This really surprised me:

gremlin> graph = TinkerFactory.createModern()
==>tinkergraph[vertices:6 edges:6]
gremlin> g = graph.traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> g.V(1)
==>v[1]
gremlin> g.V(1L)
gremlin>

We all know why it does that - I'm just amazed that createModern() isn't
rigged with an IdManager to handle it properly. createClassic() is just
fine:

gremlin> graph = TinkerFactory.createClassic()
==>tinkergraph[vertices:6 edges:6]
gremlin> g = graph.traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
gremlin> g.V(1)
==>v[1]
gremlin> g.V(1L)
==>v[1]

Going to push a fix shortly to tp31 on up (can't seem to think of a single
reason it is setup this way - so weird). I'll then issue the code freeze
email to follow.

[jira] [Commented] (TINKERPOP-1489) Provide a Javascript Gremlin Language Variant

[ASF GitHub Bot (JIRA)]

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

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

Github user jbmusso commented on the issue:

https://github.com/apache/tinkerpop/pull/450
  
@jorgebay I'd be happy to help with the work on this. I recently [added 
partial JavaScript-GLV support to 
gremlin-javascript](https://github.com/jbmusso/gremlin-javascript/tree/3bdb154f41c08d5adfc65e83250eee6d57a5cab5#experimental-javascript-gremlin-language-variant).
 The library generates Groovy strings using 
[zer](https://github.com/jbmusso/zer) which is now stable/tested enough that I 
decided to add it as a dependency to the client. I'll soon tinker with gremlin 
bytecode support in zer and I think support for lambdas is easy with 
`Function.prototype.toString()` (ref: 
[mdn](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/toString)).

We could maybe add Babel dependency with nashorn/ES5 presets, then 
parse/transpile lambdas at runtime so people can use ES2015/2016+ lambdas in 
their Node.js/browsers environments (though transpilation performance could be 
an issue, but client-side caching/memoization could certainly help).


> Provide a Javascript Gremlin Language Variant
> -
>
> Key: TINKERPOP-1489
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1489
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Reporter: Jorge Bay
>
> It would be nice to have a Javascript Gremlin Language Variant that could 
> work with any ES5 runtime, specially the ones that support 
> [CommonJs|http://requirejs.org/docs/commonjs.html], like Node.js.
> Nashorn, the engine shipped with JDK 8+, does not implement CommonJs but 
> provides [additional 
> extensions|https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions] 
> making modular JavaScript possible. Nashorn should be supported in order to 
> run glv tests under the same infrastructure (JDK8).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[DISCUSS] IBM Watson "Powered By" on homepage.

[Marko Rodriguez]

Hello,

Stephen found this New Stack article which mentions that IBM Watson using 
Apache TinkerPop.

https://twitter.com/apachetinkerpop/status/870650489716613120 


I would like to add a link to Watson in our “Powered By” section of the 
homepage.

If no one disagrees, I will add it in 72 hours.

Marko.

http://markorodriguez.com

[jira] [Commented] (TINKERPOP-1552) C# Gremlin Language Variant

[Florian Hockmann (JIRA)]

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

Florian Hockmann commented on TINKERPOP-1552:
-

So it seems that we have reached a consensus on the naming and the project 
structure which now looks like this:

{code}
gremlin-dotnet (maven module level)
  src
Gremlin.Net (C# project)
  Driver
  Process
  Structure
{code}

I will create a pull request to reorganize the project like this.

{quote}
How do we re-use the nuget package? Florian Hockmann at this point you "own" 
that package right? Is there a way to transfer that ownership to an Apache 
TinkerPop account?
{quote}
Yes, that is no problem and we should definitely do it. We just need to create 
a new account on nuget.org. Then I can add that account as an additional owner 
which gives it all permissions to manage the package.

> C# Gremlin Language Variant
> ---
>
> Key: TINKERPOP-1552
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1552
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.3
>Reporter: Jorge Bay
>Assignee: stephen mallette
>
> It would be nice to have a C# GLV that runs under .NET Framework 4.5+ and 
> .NET Core.
> The maven build could use the Exec Maven Plugin to exec .NET Core's [dotnet 
> test|https://www.microsoft.com/net/core#macos] command.
> Some requirements, from the mailing list (edited):
> {quote}
> 1. The GLV should keep in line with class/method names of the java API
> where possible to ensure consistency of feel across languages.
> 2. There needs to be adequate tests (we're still discussing the approach to
> testing GLVs and i think that needs to be tackled sooner than later as more
> GLVs start to come in). Those tests should produce xunit style output
> unless there is some good reason not to.
> 3. There needs to be adequate documentation (e.g. Reference docs)
> 4. The build/deploy process needs to be bound to maven which might be one of 
> the trickier bits to deal with.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (TINKERPOP-1552) C# Gremlin Language Variant

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1552:
-

I'm fine with Gremlin.Net. I do think the maven package should remain as 
gremlin-dotnet rather than gremlin-net, but perhaps that is obvious.

How do we re-use the nuget package? [~Florian Hockmann] at this point you "own" 
that package right? Is there a way to transfer that ownership to an Apache 
TinkerPop account?

> C# Gremlin Language Variant
> ---
>
> Key: TINKERPOP-1552
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1552
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.3
>Reporter: Jorge Bay
>Assignee: stephen mallette
>
> It would be nice to have a C# GLV that runs under .NET Framework 4.5+ and 
> .NET Core.
> The maven build could use the Exec Maven Plugin to exec .NET Core's [dotnet 
> test|https://www.microsoft.com/net/core#macos] command.
> Some requirements, from the mailing list (edited):
> {quote}
> 1. The GLV should keep in line with class/method names of the java API
> where possible to ensure consistency of feel across languages.
> 2. There needs to be adequate tests (we're still discussing the approach to
> testing GLVs and i think that needs to be tackled sooner than later as more
> GLVs start to come in). Those tests should produce xunit style output
> unless there is some good reason not to.
> 3. There needs to be adequate documentation (e.g. Reference docs)
> 4. The build/deploy process needs to be bound to maven which might be one of 
> the trickier bits to deal with.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (TINKERPOP-1552) C# Gremlin Language Variant

[Jorge Bay (JIRA)]

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

Jorge Bay edited comment on TINKERPOP-1552 at 6/2/17 11:34 AM:
---

bq. I'm personally in favor of Gremlin.Net instead of Gremlin.DotNet because it 
looks nicer in my opinion and because it would allow us to reuse the existing 
Gremlin.Net NuGet package easily. Otherwise we would end up with two packages 
on nuget.org: Gremlin.Net and Gremlin.DotNet which would only confuse users.

Gremlin.Net sounds better to me too and reusing the existing Nuget package is a 
big plus.

About whether to include the driver in the package, I think it was discussed 
back in TINKERPOP-1489 that a GLV should include a {{RemoteConnection}} 
implementation. I'm not personally interested in the {{RemoteConnection}} 
implementation but having one seems to be in the best interest of the TinkerPop 
community, regardless of our employers.


was (Author: jorgebg):
bq. I'm personally in favor of Gremlin.Net instead of Gremlin.DotNet because it 
looks nicer in my opinion and because it would allow us to reuse the existing 
Gremlin.Net NuGet package easily. Otherwise we would end up with two packages 
on nuget.org: Gremlin.Net and Gremlin.DotNet which would only confuse users.

Gremlin.Net sounds better to me too and reusing the existing Nuget package is a 
big plus.

About wether to include the driver in the package, I think it was discussed 
back in TINKERPOP-1489 that a GLV should include a {{RemoteConnection}} 
implementation. I'm not personally interested in the {{RemoteConnection}} 
implementation but having one seems to be in the best interest of the TinkerPop 
community, regardless of our employers.

> C# Gremlin Language Variant
> ---
>
> Key: TINKERPOP-1552
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1552
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.3
>Reporter: Jorge Bay
>Assignee: stephen mallette
>
> It would be nice to have a C# GLV that runs under .NET Framework 4.5+ and 
> .NET Core.
> The maven build could use the Exec Maven Plugin to exec .NET Core's [dotnet 
> test|https://www.microsoft.com/net/core#macos] command.
> Some requirements, from the mailing list (edited):
> {quote}
> 1. The GLV should keep in line with class/method names of the java API
> where possible to ensure consistency of feel across languages.
> 2. There needs to be adequate tests (we're still discussing the approach to
> testing GLVs and i think that needs to be tackled sooner than later as more
> GLVs start to come in). Those tests should produce xunit style output
> unless there is some good reason not to.
> 3. There needs to be adequate documentation (e.g. Reference docs)
> 4. The build/deploy process needs to be bound to maven which might be one of 
> the trickier bits to deal with.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (TINKERPOP-1552) C# Gremlin Language Variant

[Jorge Bay (JIRA)]

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

Jorge Bay commented on TINKERPOP-1552:
--

bq. I'm personally in favor of Gremlin.Net instead of Gremlin.DotNet because it 
looks nicer in my opinion and because it would allow us to reuse the existing 
Gremlin.Net NuGet package easily. Otherwise we would end up with two packages 
on nuget.org: Gremlin.Net and Gremlin.DotNet which would only confuse users.

Gremlin.Net sounds better to me too and reusing the existing Nuget package is a 
big plus.

About wether to include the driver in the package, I think it was discussed 
back in TINKERPOP-1489 that a GLV should include a {{RemoteConnection}} 
implementation. I'm not personally interested in the {{RemoteConnection}} 
implementation but having one seems to be in the best interest of the TinkerPop 
community, regardless of our employers.

> C# Gremlin Language Variant
> ---
>
> Key: TINKERPOP-1552
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1552
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.3
>Reporter: Jorge Bay
>Assignee: stephen mallette
>
> It would be nice to have a C# GLV that runs under .NET Framework 4.5+ and 
> .NET Core.
> The maven build could use the Exec Maven Plugin to exec .NET Core's [dotnet 
> test|https://www.microsoft.com/net/core#macos] command.
> Some requirements, from the mailing list (edited):
> {quote}
> 1. The GLV should keep in line with class/method names of the java API
> where possible to ensure consistency of feel across languages.
> 2. There needs to be adequate tests (we're still discussing the approach to
> testing GLVs and i think that needs to be tackled sooner than later as more
> GLVs start to come in). Those tests should produce xunit style output
> unless there is some good reason not to.
> 3. There needs to be adequate documentation (e.g. Reference docs)
> 4. The build/deploy process needs to be bound to maven which might be one of 
> the trickier bits to deal with.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[DISCUSS] .NET drivers featured on the website

[Florian Hockmann]

I started working on a new .NET driver for TinkerPop some time ago because I
didn't really like the way the existing .NET driver - Teva Gremlin -
abstracted away Gremlin from the user. One other important motivation was
that a driver was needed that can be used with a GLV. This new driver is
called Gremlin.Net [1] and I think that it is now in a state where it's
stable enough to be listed on TinkerPop 's website. Since an extended
version of Gremlin.Net will probably be used as the official TinkerPop
driver to support .NET GLVs (see TINKERPOP-1552 for more information [2]),
new users should probably start off with that driver to make it easy to
adopt a .NET GLV in the future. So, I propose that Gremlin.Net should be
listed as a language driver for C# / .NET.

 

It might also make sense to remove Teva Gremlin at the same time from the
list of language drivers as it is not maintained anymore:
https://github.com/effyteva/CSharpLibraries/issues/6#issuecomment-260986176

 

[1] https://github.com/FlorianHockmann/Gremlin.Net

[2] https://issues.apache.org/jira/browse/TINKERPOP-1552

[jira] [Commented] (TINKERPOP-1552) C# Gremlin Language Variant

[Florian Hockmann (JIRA)]

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

Florian Hockmann commented on TINKERPOP-1552:
-

{quote}
Its worth noting that the popularity of other languages in the .NET runtime 
compared to C# is very low. A different API for C# and VB.NET makes no sense as 
the interoperability is almost 100% and language constructs are the same (its 
more like different dialects). For F#, specific extensions could make more 
sense but it would be unlikely to be needed as C# is a "functional enough 
language" for APIs built in C# to be usable in F#. 
{quote}

After giving more thought to this I agree with you that it is probably enough 
to create one GLV for .NET that can be used by the different .NET languages. In 
the (unlikely) case that we want to support specific language features of F# or 
PowerShell in the future, we can still add them with a structure like the one 
you proposed.

And regarding the aspect of a separate NuGet package for the driver: I mainly 
had companies like DataStax in mind that provide their own drivers. But when 
you guys from DataStax now propose to build a single NuGet package that also 
includes the driver, then we should do that as it reduces the complexity for 
users.

The only remaining open question I see is the naming of the now only project / 
module / package. Should the C# project and the NuGet package be named 
{{Gremlin.DotNet}} or {{Gremlin.Net}}? And which name should we use for the 
maven module and in the documentation? I used {{DotNet}} for both as the hyphen 
version lacks the implicit dot for {{.Net}}, but I see that it could also be a 
bit confusing.
Both versions (_Net_ and _DotNet_) are frequently used in the .NET world, 
although _.Net_ seems to be a bit more popular than _DotNet_. Here are some 
popular examples for both:
* .NET:
** ASP.NET
** Json.Net (the most popular NuGet package)
** System.Net.*
** log4net
** SSH.NET
* DotNet:
** DotNetZip
** Microsoft.DotNet.*
** Docker.DotNet
I'm personally in favor of {{Gremlin.Net}} instead of {{Gremlin.DotNet}} 
because it looks nicer in my opinion and because it would allow us to reuse the 
existing {{Gremlin.Net}} NuGet package easily. Otherwise we would end up with 
two packages on nuget.org: {{Gremlin.Net}} and {{Gremlin.DotNet}} which would 
only confuse users.

> C# Gremlin Language Variant
> ---
>
> Key: TINKERPOP-1552
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1552
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.3
>Reporter: Jorge Bay
>Assignee: stephen mallette
>
> It would be nice to have a C# GLV that runs under .NET Framework 4.5+ and 
> .NET Core.
> The maven build could use the Exec Maven Plugin to exec .NET Core's [dotnet 
> test|https://www.microsoft.com/net/core#macos] command.
> Some requirements, from the mailing list (edited):
> {quote}
> 1. The GLV should keep in line with class/method names of the java API
> where possible to ensure consistency of feel across languages.
> 2. There needs to be adequate tests (we're still discussing the approach to
> testing GLVs and i think that needs to be tackled sooner than later as more
> GLVs start to come in). Those tests should produce xunit style output
> unless there is some good reason not to.
> 3. There needs to be adequate documentation (e.g. Reference docs)
> 4. The build/deploy process needs to be bound to maven which might be one of 
> the trickier bits to deal with.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (TINKERPOP-1552) C# Gremlin Language Variant

[Jorge Bay (JIRA)]

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

Jorge Bay commented on TINKERPOP-1552:
--

bq. Jorge Bay are you proposing this structure:
Yes
bq. All of that is C# then if there is a need for VB or F# specific odds and 
ends [...]
Its worth noting that the popularity of other languages in the .NET runtime 
compared to C# is very low. A different API for C# and VB.NET makes no sense as 
the interoperability is almost 100% and language constructs are the same (its 
more like different dialects). For F#, specific extensions could make more 
sense but it would be unlikely to be needed as C# is a "functional enough 
language" for APIs built in C# to be usable in F#.  
It's not common to mix .NET languages in a same solution, but due to 
limitations in the build tools (msbuild), you can not mix it in the same 
project (files contained in a csproj / fsproj). If we wanted to expose a 
different "process" API for F# in the future, it would have to be like this:
{noformat}
gremlin-dotnet (maven module level)
  src
Gremlin.DotNet
  Driver
|_ .cs files
  Process
|_ .cs files
  Structure
|_ .cs files
Gremlin.DotNet.FSharp
  Process
|_ .fs files
{noformat}
That would imply that {{Gremlin.DotNet.Process}} namespace contains the 
traversal interfaces/implementations for general use and 
{{Gremlin.DotNet.FSharp.Process}} contains members specifically designed for 
F#. But again, not very common.

> C# Gremlin Language Variant
> ---
>
> Key: TINKERPOP-1552
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1552
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: language-variant
>Affects Versions: 3.2.3
>Reporter: Jorge Bay
>Assignee: stephen mallette
>
> It would be nice to have a C# GLV that runs under .NET Framework 4.5+ and 
> .NET Core.
> The maven build could use the Exec Maven Plugin to exec .NET Core's [dotnet 
> test|https://www.microsoft.com/net/core#macos] command.
> Some requirements, from the mailing list (edited):
> {quote}
> 1. The GLV should keep in line with class/method names of the java API
> where possible to ensure consistency of feel across languages.
> 2. There needs to be adequate tests (we're still discussing the approach to
> testing GLVs and i think that needs to be tackled sooner than later as more
> GLVs start to come in). Those tests should produce xunit style output
> unless there is some good reason not to.
> 3. There needs to be adequate documentation (e.g. Reference docs)
> 4. The build/deploy process needs to be bound to maven which might be one of 
> the trickier bits to deal with.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (TINKERPOP-1683) AbstractHadoopGraphComputer on Windows

[Felix Hill (JIRA)]

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

Felix Hill commented on TINKERPOP-1683:
---

The correct RegEx would be
\[^;\]*+*
instead of
\[^;\]

change PATH_PATTERN accordingly:

{code:title=AbstractHadoopGraphComputer.java|borderStyle=solid}
private final static Pattern PATH_PATTERN =
Pattern.compile(File.pathSeparator.equals(":") ? "([^:]|://)+" : 
("[^" + File.pathSeparator + "]+"));
{code}

> AbstractHadoopGraphComputer on Windows
> --
>
> Key: TINKERPOP-1683
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1683
> Project: TinkerPop
>  Issue Type: Bug
>  Components: hadoop
>Affects Versions: 3.3.0
> Environment: Windows
>Reporter: Felix Hill
>Priority: Trivial
>  Labels: RegEx
>   Original Estimate: 0.25h
>  Remaining Estimate: 0.25h
>
> AbstractHadoopGraphComputer splits *HADOOP_GREMLIN_LIBS* in a wrong way if ; 
> is the File.pathSeparator (on windows).
> Here, the produced PATH_PATTERN splits a path at each character not at each 
> seperator.
> {code:title=AbstractHadoopGraphComputer.java|borderStyle=solid}
> private final static Pattern PATH_PATTERN =
> Pattern.compile(File.pathSeparator.equals(":") ? "([^:]|://)+" : 
> ("[^" + File.pathSeparator + "]"));
> final Matcher matcher = PATH_PATTERN.matcher(hadoopGremlinLibs);
> while (matcher.find()) {
> final String path = matcher.group();
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)