[jira] [Commented] (TINKERPOP-2070) gremlin-javascript: Introduce Connection representation
[
https://issues.apache.org/jira/browse/TINKERPOP-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665752#comment-16665752
]
Matthew Allen commented on TINKERPOP-2070:
--
Could I suggest this be added to the tp32 branch as well. Would make the api
much more user friendly...
> gremlin-javascript: Introduce Connection representation
> ---
>
> Key: TINKERPOP-2070
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2070
> Project: TinkerPop
> Issue Type: Improvement
> Components: javascript
>Affects Versions: 3.3.4
>Reporter: Jorge Bay
>Assignee: Jorge Bay
>Priority: Major
> Fix For: 3.4.0, 3.3.5
>
>
> Currently on gremlin-javascript, {{DriverRemoteConnection}} represents a
> single connection to the server and a {{RemoteConnection}} implementation.
> Like Python and .NET, we need to make the {{DriverRemoteConnection}} use the
> {{Client}} instead of interacting with the websocket directly.
> The dependency tree between classes should be like the following
> {code:java}
> DriverRemoteConnection
> |_ Client
> |_ Connection
> {code}
> These changes don't involve a breaking change, its more of an implementation
> issue. As {{DriverRemoteConnection}} is part of the public API the current
> implementation is a limitation.
> This blocks or at least forces awful workarounds for improvements like
> TINKERPOP-2064.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-2082) g:Set type is not be validated in some variant tests
stephen mallette created TINKERPOP-2082:
---
Summary: g:Set type is not be validated in some variant tests
Key: TINKERPOP-2082
URL: https://issues.apache.org/jira/browse/TINKERPOP-2082
Project: TinkerPop
Issue Type: Improvement
Components: dotnet, javascript
Affects Versions: 3.3.4
Reporter: stephen mallette
{{g:Set}} as a type is not being validated by .NET or javascript as noticed
here with this change:
https://github.com/apache/tinkerpop/pull/964/files#diff-bc849673baf1f7ed925db681d0cc112c
Javascript test harness for cucumber tests just coerces both {{s[]}} and
{{l[]}} with {{toArray}} and .NET coerces both to a list and then if a {{s[]}}
to a {{Set}} but doesn't bother to assert that the type is legit.
If javascript can't support set/list semantics for some reason, [~jorgebg]
please remove the "javascript" from the "component" field and we won't bother
to worry about it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TINKERPOP-2062) Add Traversal class to CoreImports
[
https://issues.apache.org/jira/browse/TINKERPOP-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kuppitz closed TINKERPOP-2062.
-
Resolution: Fixed
Fix Version/s: 3.3.5
3.4.0
> Add Traversal class to CoreImports
> --
>
> Key: TINKERPOP-2062
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2062
> Project: TinkerPop
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.3.3
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Minor
> Fix For: 3.4.0, 3.3.5
>
>
> Apparently, some people like to copy Gremlin queries they've written in Java
> and paste them into the Gremlin console. This should usually work pretty
> well, however, there are some oddities in particular with {{union()}} step
> which requires you to cast the child traversals to {{Traversal}} if they have
> different return types, e.g.:
> {noformat}
> g.V().
> union(
> __.identity(),
> (Traversal)__.outE()
> )
> {noformat}
> This works in a local console session but fails if the query is sent to a
> server as {{Traversal}} is not part of the core imports.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2062) Add Traversal class to CoreImports
[
https://issues.apache.org/jira/browse/TINKERPOP-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665561#comment-16665561
]
ASF GitHub Bot commented on TINKERPOP-2062:
---
dkuppitz closed pull request #971: TINKERPOP-2062 added Traversal class to
CoreImports
URL: https://github.com/apache/tinkerpop/pull/971
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Add Traversal class to CoreImports
> --
>
> Key: TINKERPOP-2062
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2062
> Project: TinkerPop
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.3.3
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Minor
>
> Apparently, some people like to copy Gremlin queries they've written in Java
> and paste them into the Gremlin console. This should usually work pretty
> well, however, there are some oddities in particular with {{union()}} step
> which requires you to cast the child traversals to {{Traversal}} if they have
> different return types, e.g.:
> {noformat}
> g.V().
> union(
> __.identity(),
> (Traversal)__.outE()
> )
> {noformat}
> This works in a local console session but fails if the query is sent to a
> server as {{Traversal}} is not part of the core imports.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [tinkerpop] dkuppitz closed pull request #971: TINKERPOP-2062 added Traversal class to CoreImports
[ pull request closed by dkuppitz ] [ Full content available at: https://github.com/apache/tinkerpop/pull/971 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[GitHub] [tinkerpop] aboudreault commented on issue #964: TINKERPOP-2071: gremlin-python: g:Set graphson deserializer should return a python set
@spmallette Let me look at how this scenario stuff works. I will add one that return a list. [ Full content available at: https://github.com/apache/tinkerpop/pull/964 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[GitHub] [tinkerpop] spmallette commented on issue #964: TINKERPOP-2071: gremlin-python: g:Set graphson deserializer should return a python set
I re-ran the travis build and the error is gone. probably a fluke of travis or something. I guess this is good now. do you happen to know if there is a test for the alternative scenario somewhere (i.e. where a set becomes a list)? [ Full content available at: https://github.com/apache/tinkerpop/pull/964 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[jira] [Commented] (TINKERPOP-2067) Allow getting raw data from Gremlin.Net.Driver.IGremlinClient
[ https://issues.apache.org/jira/browse/TINKERPOP-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665403#comment-16665403 ] Daniel C. Weber commented on TINKERPOP-2067: I revised the test to force a response from the server (i.e. it now doesn't query g.V()... anymore). Connection also would do aggregation in the JToken case, although I'm afraid I don't know what it would mean in that case or how it would look, sorry. > Allow getting raw data from Gremlin.Net.Driver.IGremlinClient > - > > Key: TINKERPOP-2067 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2067 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.3.3 >Reporter: Daniel C. Weber >Priority: Minor > > I am developing an ORM-style [server driver for > Gremlin|https://github.com/ExRam/ExRam.Gremlinq]. To communicate with > Gremlin-servers, I rely on > [Gremlin.net|https://github.com/ExRam/ExRam.Gremlinq/tree/master/ExRam.Gremlinq.Providers.WebSocket]. > Since ExRam.Gremlinq deals with deserializing Json data to POCOs by itself, > it needs to get raw data from an IGremlinClient. Currently, it's only safe to > use SubmitAsync with object or dynamic as T, or other (scalar) types if > known it advance. To get a raw JToken, I currently use a > [hack|https://github.com/ExRam/ExRam.Gremlinq/blob/master/ExRam.Gremlinq.Providers.WebSocket/GremlinClientQueryProvider.cs#L34]. > The hack is not only ugly, it prohibits users of ExRam.Gremlinq to create and > pass in instances of IGremlinClient by themselves, which could become > necessary e.g. for adjusting the Graphson version etc. > I had a look into the sources of Gremlin.net. It deserializes a server's > answer to a ResponseMessage, so the JToken is available in any case. > It would be a trivial change to check the type parameter T and return the > token if typeof(T) == typeof(JToken), and I could definitely file the PR for > that. However, I'm of course less aware of possible unintended implications. > Any thoughts are appreciated! > > thx > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2067) Allow getting raw data from Gremlin.Net.Driver.IGremlinClient
[ https://issues.apache.org/jira/browse/TINKERPOP-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665372#comment-16665372 ] Daniel C. Weber commented on TINKERPOP-2067: I meant only that build job was failing. Apparently, the server response for the query is different in the particular build job. > Allow getting raw data from Gremlin.Net.Driver.IGremlinClient > - > > Key: TINKERPOP-2067 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2067 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.3.3 >Reporter: Daniel C. Weber >Priority: Minor > > I am developing an ORM-style [server driver for > Gremlin|https://github.com/ExRam/ExRam.Gremlinq]. To communicate with > Gremlin-servers, I rely on > [Gremlin.net|https://github.com/ExRam/ExRam.Gremlinq/tree/master/ExRam.Gremlinq.Providers.WebSocket]. > Since ExRam.Gremlinq deals with deserializing Json data to POCOs by itself, > it needs to get raw data from an IGremlinClient. Currently, it's only safe to > use SubmitAsync with object or dynamic as T, or other (scalar) types if > known it advance. To get a raw JToken, I currently use a > [hack|https://github.com/ExRam/ExRam.Gremlinq/blob/master/ExRam.Gremlinq.Providers.WebSocket/GremlinClientQueryProvider.cs#L34]. > The hack is not only ugly, it prohibits users of ExRam.Gremlinq to create and > pass in instances of IGremlinClient by themselves, which could become > necessary e.g. for adjusting the Graphson version etc. > I had a look into the sources of Gremlin.net. It deserializes a server's > answer to a ResponseMessage, so the JToken is available in any case. > It would be a trivial change to check the type parameter T and return the > token if typeof(T) == typeof(JToken), and I could definitely file the PR for > that. However, I'm of course less aware of possible unintended implications. > Any thoughts are appreciated! > > thx > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (TINKERPOP-2067) Allow getting raw data from Gremlin.Net.Driver.IGremlinClient
[
https://issues.apache.org/jira/browse/TINKERPOP-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665354#comment-16665354
]
Florian Hockmann edited comment on TINKERPOP-2067 at 10/26/18 4:10 PM:
---
What do you mean with "only for that run"? The other runs are for Python, JS,
Spark, and the main project or did you start other full runs with Travis
somewhere else? So, did this test work somewhere else?
To me it looks as if you should really get back {{null}} from the server here
because there exists no vertex that matches your filter criteria.
But yes, I think that you also need to handle the aggregation of data even if
{{typeof(T) == typeof(JToken)}}:
was (Author: florian hockmann):
What do you mean with "only for that run"? The other runs are for Python, JS,
Spark, and the main project or did you start other full runs with Travis
somewhere else? So, did this test work somewhere else?
To me it looks as if you should really get back {{null}} from the server here
because there exists no vertex that matches your filter criteria.
> Allow getting raw data from Gremlin.Net.Driver.IGremlinClient
> -
>
> Key: TINKERPOP-2067
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2067
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.3.3
>Reporter: Daniel C. Weber
>Priority: Minor
>
> I am developing an ORM-style [server driver for
> Gremlin|https://github.com/ExRam/ExRam.Gremlinq]. To communicate with
> Gremlin-servers, I rely on
> [Gremlin.net|https://github.com/ExRam/ExRam.Gremlinq/tree/master/ExRam.Gremlinq.Providers.WebSocket].
> Since ExRam.Gremlinq deals with deserializing Json data to POCOs by itself,
> it needs to get raw data from an IGremlinClient. Currently, it's only safe to
> use SubmitAsync with object or dynamic as T, or other (scalar) types if
> known it advance. To get a raw JToken, I currently use a
> [hack|https://github.com/ExRam/ExRam.Gremlinq/blob/master/ExRam.Gremlinq.Providers.WebSocket/GremlinClientQueryProvider.cs#L34].
> The hack is not only ugly, it prohibits users of ExRam.Gremlinq to create and
> pass in instances of IGremlinClient by themselves, which could become
> necessary e.g. for adjusting the Graphson version etc.
> I had a look into the sources of Gremlin.net. It deserializes a server's
> answer to a ResponseMessage, so the JToken is available in any case.
> It would be a trivial change to check the type parameter T and return the
> token if typeof(T) == typeof(JToken), and I could definitely file the PR for
> that. However, I'm of course less aware of possible unintended implications.
> Any thoughts are appreciated!
>
> thx
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2067) Allow getting raw data from Gremlin.Net.Driver.IGremlinClient
[
https://issues.apache.org/jira/browse/TINKERPOP-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665354#comment-16665354
]
Florian Hockmann commented on TINKERPOP-2067:
-
What do you mean with "only for that run"? The other runs are for Python, JS,
Spark, and the main project or did you start other full runs with Travis
somewhere else? So, did this test work somewhere else?
To me it looks as if you should really get back {{null}} from the server here
because there exists no vertex that matches your filter criteria.
> Allow getting raw data from Gremlin.Net.Driver.IGremlinClient
> -
>
> Key: TINKERPOP-2067
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2067
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.3.3
>Reporter: Daniel C. Weber
>Priority: Minor
>
> I am developing an ORM-style [server driver for
> Gremlin|https://github.com/ExRam/ExRam.Gremlinq]. To communicate with
> Gremlin-servers, I rely on
> [Gremlin.net|https://github.com/ExRam/ExRam.Gremlinq/tree/master/ExRam.Gremlinq.Providers.WebSocket].
> Since ExRam.Gremlinq deals with deserializing Json data to POCOs by itself,
> it needs to get raw data from an IGremlinClient. Currently, it's only safe to
> use SubmitAsync with object or dynamic as T, or other (scalar) types if
> known it advance. To get a raw JToken, I currently use a
> [hack|https://github.com/ExRam/ExRam.Gremlinq/blob/master/ExRam.Gremlinq.Providers.WebSocket/GremlinClientQueryProvider.cs#L34].
> The hack is not only ugly, it prohibits users of ExRam.Gremlinq to create and
> pass in instances of IGremlinClient by themselves, which could become
> necessary e.g. for adjusting the Graphson version etc.
> I had a look into the sources of Gremlin.net. It deserializes a server's
> answer to a ResponseMessage, so the JToken is available in any case.
> It would be a trivial change to check the type parameter T and return the
> token if typeof(T) == typeof(JToken), and I could definitely file the PR for
> that. However, I'm of course less aware of possible unintended implications.
> Any thoughts are appreciated!
>
> thx
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (TINKERPOP-2067) Allow getting raw data from Gremlin.Net.Driver.IGremlinClient
[ https://issues.apache.org/jira/browse/TINKERPOP-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665343#comment-16665343 ] Daniel C. Weber edited comment on TINKERPOP-2067 at 10/26/18 4:01 PM: -- It is, but why only for that run? Also, is "Could not deserialize the Traversal instance" below related to that? I guess there is more to it than just the simple type-check. Could the response from the server in that run indeed contain "null" for receivedMsg.Result.Data, and an accumulation is required? was (Author: daniel.weber): It is, but why only for that run? Also, is "Could not deserialize the Traversal instance" below related to that? I guess there is more to it than just the simple type-check. Could the response from the server in that run indeed contain "null" for data, and an accumulation is required? > Allow getting raw data from Gremlin.Net.Driver.IGremlinClient > - > > Key: TINKERPOP-2067 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2067 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.3.3 >Reporter: Daniel C. Weber >Priority: Minor > > I am developing an ORM-style [server driver for > Gremlin|https://github.com/ExRam/ExRam.Gremlinq]. To communicate with > Gremlin-servers, I rely on > [Gremlin.net|https://github.com/ExRam/ExRam.Gremlinq/tree/master/ExRam.Gremlinq.Providers.WebSocket]. > Since ExRam.Gremlinq deals with deserializing Json data to POCOs by itself, > it needs to get raw data from an IGremlinClient. Currently, it's only safe to > use SubmitAsync with object or dynamic as T, or other (scalar) types if > known it advance. To get a raw JToken, I currently use a > [hack|https://github.com/ExRam/ExRam.Gremlinq/blob/master/ExRam.Gremlinq.Providers.WebSocket/GremlinClientQueryProvider.cs#L34]. > The hack is not only ugly, it prohibits users of ExRam.Gremlinq to create and > pass in instances of IGremlinClient by themselves, which could become > necessary e.g. for adjusting the Graphson version etc. > I had a look into the sources of Gremlin.net. It deserializes a server's > answer to a ResponseMessage, so the JToken is available in any case. > It would be a trivial change to check the type parameter T and return the > token if typeof(T) == typeof(JToken), and I could definitely file the PR for > that. However, I'm of course less aware of possible unintended implications. > Any thoughts are appreciated! > > thx > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (TINKERPOP-2067) Allow getting raw data from Gremlin.Net.Driver.IGremlinClient
[ https://issues.apache.org/jira/browse/TINKERPOP-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665343#comment-16665343 ] Daniel C. Weber edited comment on TINKERPOP-2067 at 10/26/18 4:00 PM: -- It is, but why only for that run? Also, is "Could not deserialize the Traversal instance" below related to that? I guess there is more to it than just the simple type-check. Could the response from the server in that run indeed contain "null" for data, and an accumulation is required? was (Author: daniel.weber): It is, but why only for that run? Also, is Could not deserialize the Traversal instance below related to that? I guess there is more to it than just the simple type-check. Could the response from the server in that run indeed contain "null" for data, and an accumulation is required? > Allow getting raw data from Gremlin.Net.Driver.IGremlinClient > - > > Key: TINKERPOP-2067 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2067 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.3.3 >Reporter: Daniel C. Weber >Priority: Minor > > I am developing an ORM-style [server driver for > Gremlin|https://github.com/ExRam/ExRam.Gremlinq]. To communicate with > Gremlin-servers, I rely on > [Gremlin.net|https://github.com/ExRam/ExRam.Gremlinq/tree/master/ExRam.Gremlinq.Providers.WebSocket]. > Since ExRam.Gremlinq deals with deserializing Json data to POCOs by itself, > it needs to get raw data from an IGremlinClient. Currently, it's only safe to > use SubmitAsync with object or dynamic as T, or other (scalar) types if > known it advance. To get a raw JToken, I currently use a > [hack|https://github.com/ExRam/ExRam.Gremlinq/blob/master/ExRam.Gremlinq.Providers.WebSocket/GremlinClientQueryProvider.cs#L34]. > The hack is not only ugly, it prohibits users of ExRam.Gremlinq to create and > pass in instances of IGremlinClient by themselves, which could become > necessary e.g. for adjusting the Graphson version etc. > I had a look into the sources of Gremlin.net. It deserializes a server's > answer to a ResponseMessage, so the JToken is available in any case. > It would be a trivial change to check the type parameter T and return the > token if typeof(T) == typeof(JToken), and I could definitely file the PR for > that. However, I'm of course less aware of possible unintended implications. > Any thoughts are appreciated! > > thx > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2067) Allow getting raw data from Gremlin.Net.Driver.IGremlinClient
[ https://issues.apache.org/jira/browse/TINKERPOP-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665343#comment-16665343 ] Daniel C. Weber commented on TINKERPOP-2067: It is, but why only for that run? Also, is Could not deserialize the Traversal instance below related to that? I guess there is more to it than just the simple type-check. Could the response from the server in that run indeed contain "null" for data, and an accumulation is required? > Allow getting raw data from Gremlin.Net.Driver.IGremlinClient > - > > Key: TINKERPOP-2067 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2067 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.3.3 >Reporter: Daniel C. Weber >Priority: Minor > > I am developing an ORM-style [server driver for > Gremlin|https://github.com/ExRam/ExRam.Gremlinq]. To communicate with > Gremlin-servers, I rely on > [Gremlin.net|https://github.com/ExRam/ExRam.Gremlinq/tree/master/ExRam.Gremlinq.Providers.WebSocket]. > Since ExRam.Gremlinq deals with deserializing Json data to POCOs by itself, > it needs to get raw data from an IGremlinClient. Currently, it's only safe to > use SubmitAsync with object or dynamic as T, or other (scalar) types if > known it advance. To get a raw JToken, I currently use a > [hack|https://github.com/ExRam/ExRam.Gremlinq/blob/master/ExRam.Gremlinq.Providers.WebSocket/GremlinClientQueryProvider.cs#L34]. > The hack is not only ugly, it prohibits users of ExRam.Gremlinq to create and > pass in instances of IGremlinClient by themselves, which could become > necessary e.g. for adjusting the Graphson version etc. > I had a look into the sources of Gremlin.net. It deserializes a server's > answer to a ResponseMessage, so the JToken is available in any case. > It would be a trivial change to check the type parameter T and return the > token if typeof(T) == typeof(JToken), and I could definitely file the PR for > that. However, I'm of course less aware of possible unintended implications. > Any thoughts are appreciated! > > thx > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2074) Ensure that only NuGet packages for the current version are pushed
[
https://issues.apache.org/jira/browse/TINKERPOP-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665337#comment-16665337
]
Florian Hockmann commented on TINKERPOP-2074:
-
The fix was really trivial, so I pushed it with a CTR commit. I only had to
replace the {{*}} with {{${project.version\}}} in the command from the
description:
[7445d18b05791e210c5d2682d7893ee4d47edb0a|https://github.com/apache/tinkerpop/commit/7445d18b05791e210c5d2682d7893ee4d47edb0a]
I also tested the change locally by changing the deployment target from
nuget.org to a file path:
{code:sh}
[exec] Pushing Gremlin.Net.3.3.5-SNAPSHOT.nupkg to '/tmp/nuget'...
[exec] Your package was pushed.
[exec] Pushing Gremlin.Net.Template.3.3.5-SNAPSHOT.nupkg to '/tmp/nuget'...
[exec] Your package was pushed.
{code}
Since I also had packages for 3.4.0-SNAPSHOT ready, the fix seems to work as
nuget.exe didn't try to also push them.
> Ensure that only NuGet packages for the current version are pushed
> --
>
> Key: TINKERPOP-2074
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2074
> Project: TinkerPop
> Issue Type: Improvement
> Components: build-release, dotnet
>Reporter: Florian Hockmann
>Priority: Minor
> Fix For: 3.4.0, 3.3.5
>
>
> We currently use this command to push the NuGet packages to nuget.org:
> {code}
> ${nugetExe} push Gremlin.Net/bin/Gremlin.Net.*.nupkg [...]{code}
> which will push all versions of the package it can find in the
> {{Gremlin.Net/bin}} directory. The same applies to the Gremlin.Net.Template.
> We should use the exact version here instead to avoid pushing packages for
> any other versions by accident.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TINKERPOP-2074) Ensure that only NuGet packages for the current version are pushed
[
https://issues.apache.org/jira/browse/TINKERPOP-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Florian Hockmann closed TINKERPOP-2074.
---
Resolution: Fixed
Assignee: Florian Hockmann
Fix Version/s: 3.3.5
3.4.0
> Ensure that only NuGet packages for the current version are pushed
> --
>
> Key: TINKERPOP-2074
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2074
> Project: TinkerPop
> Issue Type: Improvement
> Components: build-release, dotnet
>Reporter: Florian Hockmann
>Assignee: Florian Hockmann
>Priority: Minor
> Fix For: 3.4.0, 3.3.5
>
>
> We currently use this command to push the NuGet packages to nuget.org:
> {code}
> ${nugetExe} push Gremlin.Net/bin/Gremlin.Net.*.nupkg [...]{code}
> which will push all versions of the package it can find in the
> {{Gremlin.Net/bin}} directory. The same applies to the Gremlin.Net.Template.
> We should use the exact version here instead to avoid pushing packages for
> any other versions by accident.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2067) Allow getting raw data from Gremlin.Net.Driver.IGremlinClient
[
https://issues.apache.org/jira/browse/TINKERPOP-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665306#comment-16665306
]
Florian Hockmann commented on TINKERPOP-2067:
-
It's a bit hard to find a failing test in this really long output, but it's
this one:
{code:java}
Gremlin.Net.IntegrationTest.Driver.GremlinClientTests.ShouldHandle_JToken_Request
[FAIL]
Failed
Gremlin.Net.IntegrationTest.Driver.GremlinClientTests.ShouldHandle_JToken_Request
Error Message:
Assert.NotNull() Failure
Stack Trace:
at
Gremlin.Net.IntegrationTest.Driver.GremlinClientTests.ShouldHandle_JToken_Request()
in
/home/travis/build/apache/tinkerpop/gremlin-dotnet/test/Gremlin.Net.IntegrationTest/Driver/GremlinClientTests.cs:line
81{code}
Isn't that the test you added to test the new functionality?
> Allow getting raw data from Gremlin.Net.Driver.IGremlinClient
> -
>
> Key: TINKERPOP-2067
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2067
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.3.3
>Reporter: Daniel C. Weber
>Priority: Minor
>
> I am developing an ORM-style [server driver for
> Gremlin|https://github.com/ExRam/ExRam.Gremlinq]. To communicate with
> Gremlin-servers, I rely on
> [Gremlin.net|https://github.com/ExRam/ExRam.Gremlinq/tree/master/ExRam.Gremlinq.Providers.WebSocket].
> Since ExRam.Gremlinq deals with deserializing Json data to POCOs by itself,
> it needs to get raw data from an IGremlinClient. Currently, it's only safe to
> use SubmitAsync with object or dynamic as T, or other (scalar) types if
> known it advance. To get a raw JToken, I currently use a
> [hack|https://github.com/ExRam/ExRam.Gremlinq/blob/master/ExRam.Gremlinq.Providers.WebSocket/GremlinClientQueryProvider.cs#L34].
> The hack is not only ugly, it prohibits users of ExRam.Gremlinq to create and
> pass in instances of IGremlinClient by themselves, which could become
> necessary e.g. for adjusting the Graphson version etc.
> I had a look into the sources of Gremlin.net. It deserializes a server's
> answer to a ResponseMessage, so the JToken is available in any case.
> It would be a trivial change to check the type parameter T and return the
> token if typeof(T) == typeof(JToken), and I could definitely file the PR for
> that. However, I'm of course less aware of possible unintended implications.
> Any thoughts are appreciated!
>
> thx
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2067) Allow getting raw data from Gremlin.Net.Driver.IGremlinClient
[ https://issues.apache.org/jira/browse/TINKERPOP-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665303#comment-16665303 ] Daniel C. Weber commented on TINKERPOP-2067: I don't have enough insight into the integration tests to see why [https://travis-ci.org/apache/tinkerpop/jobs/446744332] is failing (all other jobs succeed). > Allow getting raw data from Gremlin.Net.Driver.IGremlinClient > - > > Key: TINKERPOP-2067 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2067 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.3.3 >Reporter: Daniel C. Weber >Priority: Minor > > I am developing an ORM-style [server driver for > Gremlin|https://github.com/ExRam/ExRam.Gremlinq]. To communicate with > Gremlin-servers, I rely on > [Gremlin.net|https://github.com/ExRam/ExRam.Gremlinq/tree/master/ExRam.Gremlinq.Providers.WebSocket]. > Since ExRam.Gremlinq deals with deserializing Json data to POCOs by itself, > it needs to get raw data from an IGremlinClient. Currently, it's only safe to > use SubmitAsync with object or dynamic as T, or other (scalar) types if > known it advance. To get a raw JToken, I currently use a > [hack|https://github.com/ExRam/ExRam.Gremlinq/blob/master/ExRam.Gremlinq.Providers.WebSocket/GremlinClientQueryProvider.cs#L34]. > The hack is not only ugly, it prohibits users of ExRam.Gremlinq to create and > pass in instances of IGremlinClient by themselves, which could become > necessary e.g. for adjusting the Graphson version etc. > I had a look into the sources of Gremlin.net. It deserializes a server's > answer to a ResponseMessage, so the JToken is available in any case. > It would be a trivial change to check the type parameter T and return the > token if typeof(T) == typeof(JToken), and I could definitely file the PR for > that. However, I'm of course less aware of possible unintended implications. > Any thoughts are appreciated! > > thx > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2081) PersistedOutputRDD materialises rdd lazily with Spark 2.x
[ https://issues.apache.org/jira/browse/TINKERPOP-2081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665290#comment-16665290 ] ASF GitHub Bot commented on TINKERPOP-2081: --- artem-aliev opened a new pull request #973: TINKERPOP-2081: Fix PersistedOutputRDD to eager persist RDD URL: https://github.com/apache/tinkerpop/pull/973 call rdd.count() action to trigger the caching This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > PersistedOutputRDD materialises rdd lazily with Spark 2.x > - > > Key: TINKERPOP-2081 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2081 > Project: TinkerPop > Issue Type: Bug >Affects Versions: 3.3.4 >Reporter: Artem Aliev >Priority: Major > > PersistedOutputRDD is not actually persist RDD in spark memory but mark it > for lazy caching in the future. It looks like caching was eager in Spark 1.6, > but in spark 2.0 it lazy. > The lazy caching looks wrong for this case, the source graph could be changed > after snapshot is created and snapshot should not be affected by that changes. > The fix itself is simple: PersistedOutputRDD should call any spark action to > trigger eager caching. For example count() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2067) Allow getting raw data from Gremlin.Net.Driver.IGremlinClient
[ https://issues.apache.org/jira/browse/TINKERPOP-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665251#comment-16665251 ] ASF GitHub Bot commented on TINKERPOP-2067: --- danielcweber opened a new pull request #972: TINKERPOP-2067 Allow getting raw JToken data from Gremlin.Net.Driver.GremlinClient. URL: https://github.com/apache/tinkerpop/pull/972 https://issues.apache.org/jira/browse/TINKERPOP-2067 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Allow getting raw data from Gremlin.Net.Driver.IGremlinClient > - > > Key: TINKERPOP-2067 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2067 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.3.3 >Reporter: Daniel C. Weber >Priority: Minor > > I am developing an ORM-style [server driver for > Gremlin|https://github.com/ExRam/ExRam.Gremlinq]. To communicate with > Gremlin-servers, I rely on > [Gremlin.net|https://github.com/ExRam/ExRam.Gremlinq/tree/master/ExRam.Gremlinq.Providers.WebSocket]. > Since ExRam.Gremlinq deals with deserializing Json data to POCOs by itself, > it needs to get raw data from an IGremlinClient. Currently, it's only safe to > use SubmitAsync with object or dynamic as T, or other (scalar) types if > known it advance. To get a raw JToken, I currently use a > [hack|https://github.com/ExRam/ExRam.Gremlinq/blob/master/ExRam.Gremlinq.Providers.WebSocket/GremlinClientQueryProvider.cs#L34]. > The hack is not only ugly, it prohibits users of ExRam.Gremlinq to create and > pass in instances of IGremlinClient by themselves, which could become > necessary e.g. for adjusting the Graphson version etc. > I had a look into the sources of Gremlin.net. It deserializes a server's > answer to a ResponseMessage, so the JToken is available in any case. > It would be a trivial change to check the type parameter T and return the > token if typeof(T) == typeof(JToken), and I could definitely file the PR for > that. However, I'm of course less aware of possible unintended implications. > Any thoughts are appreciated! > > thx > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [tinkerpop] danielcweber opened pull request #972: TINKERPOP-2067 Allow getting raw JToken data from Gremlin.Net.Driver.GremlinClient.
https://issues.apache.org/jira/browse/TINKERPOP-2067 [ Full content available at: https://github.com/apache/tinkerpop/pull/972 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[jira] [Created] (TINKERPOP-2081) PersistedOutputRDD materialises rdd lazily with Spark 2.x
Artem Aliev created TINKERPOP-2081: -- Summary: PersistedOutputRDD materialises rdd lazily with Spark 2.x Key: TINKERPOP-2081 URL: https://issues.apache.org/jira/browse/TINKERPOP-2081 Project: TinkerPop Issue Type: Bug Affects Versions: 3.3.4 Reporter: Artem Aliev PersistedOutputRDD is not actually persist RDD in spark memory but mark it for lazy caching in the future. It looks like caching was eager in Spark 1.6, but in spark 2.0 it lazy. The lazy caching looks wrong for this case, the source graph could be changed after snapshot is created and snapshot should not be affected by that changes. The fix itself is simple: PersistedOutputRDD should call any spark action to trigger eager caching. For example count() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: code freeze 3.2.10/3.3.4
I'm +0 on formalizing too muchsome common sense like "release next
cycle unless someone can provide a proof of concept or just feels strongly
otherwise" is fine by me.
> If you're going to reopen tp32, then I'll retarget
sounds good - thanks for staying up on the "security" stuff
On Fri, Oct 26, 2018 at 8:06 AM Robert Dale wrote:
> If you're going to reopen tp32, then I'll retarget
> https://github.com/apache/tinkerpop/pull/969
>
> Robert Dale
>
>
> On Fri, Oct 26, 2018 at 7:56 AM Robert Dale wrote:
>
> > So to answer your earlier question on security fixes, the driver should
> be
> > our security policy ;-)
> >
> > For example, if tp32 is not officially closed and accepts bug fixes, and
> > given "security problems are just bugs" [1], then tp32 should get
> > security-related bug fixes.
> >
> > We can use CVSS [2] to score vulnerabilities. They even have a
> handy-dandy
> > calculator [3].
> >
> > The release trigger should also be in the security policy. It could be
> > based on the CVSS score:
> > <5, next scheduled release
> > <7, within 30 days
> > <8, within 2 weeks
> > <9, within 1 week
> > 9+, asap
> >
> > Or we just keep it simple, release next cycle unless someone can provide
> a
> > proof of concept or just feels strongly otherwise.
> >
> > For example, I don't think TINKERPOP-2068 [4] is critical because our
> > serializers handle only explicitly listed types. Nothing is blindly
> > delegated to Jackson. No need for an emergency release. Someone can
> confirm.
> >
> > 1. https://lkml.org/lkml/2017/11/17/767
> > 2. https://www.first.org/cvss/
> > 3. https://www.first.org/cvss/calculator/3.0
> > 4. https://issues.apache.org/jira/browse/TINKERPOP-2068
> >
> > Robert Dale
> >
> >
> > On Fri, Oct 26, 2018 at 7:02 AM Stephen Mallette
> > wrote:
> >
> >> tp32...
> >>
> >> i started thinking that we could keep a JIRA ticket open that had a list
> >> of
> >> bugs we might backport to tp32 should we have some triggering event,
> >> buti dunno. maybe we go with a first step at this and re-open the
> >> branch but just ship security+bug fixes at it and not try to wait for a
> >> triggering event for release. i would expect the CHANGELOG for 3.2.11 to
> >> be
> >> really small if we do this right. please let me know if there are any
> >> concerns, otherwise we'll start heading down this route and i'll re-open
> >> the branch on Monday.
> >>
> >> On Mon, Oct 22, 2018 at 11:42 AM Stephen Mallette >
> >> wrote:
> >>
> >> > there's always going to be those kinds of things though right? can we
> >> get
> >> > away with doing stuff to tp32 only when there is some specific demand
> >> for a
> >> > 3.2.11. like, that fix on its own doesn't feel like something we'd
> >> trigger
> >> > a release overor would we?
> >> >
> >> > On Sat, Oct 20, 2018 at 9:27 AM Robert Dale
> wrote:
> >> >
> >> >> You don't want to put
> >> >> https://issues.apache.org/jira/browse/TINKERPOP-2068
> >> >> on tp32?
> >> >>
> >> >> Robert Dale
> >> >>
> >> >>
> >> >> On Fri, Oct 19, 2018 at 6:03 PM Stephen Mallette <
> spmalle...@gmail.com
> >> >
> >> >> wrote:
> >> >>
> >> >> > > I created a ticket to track this and I can probably take care of
> >> it
> >> >> next
> >> >> > week
> >> >> >
> >> >> > that makes sense, thank you.
> >> >> >
> >> >> > separately, code freeze is now lifted on tp33 - i've bumped to
> >> >> > 3.3.5-SNAPSHOT, published initial docs/artifacts and all is good to
> >> go.
> >> >> > I've left tp32 on 3.2.10 until we decide to actually do something
> on
> >> >> that
> >> >> > branch. For now, we'll just say we're done there as we discussed
> >> >> > elsethread.
> >> >> >
> >> >> > kuppitz, feel free to fire up the dead branch cleanup email. i
> wonder
> >> >> if it
> >> >> > will be more convenient to delete branches as we go now that we
> have
> >> the
> >> >> > github UI available to us. might be good to just hit the "delete
> >> branch"
> >> >> > button right when we hit the merge one.
> >> >> >
> >> >> > i will announce the releases on monday morning EST time.
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Fri, Oct 19, 2018 at 5:04 PM Florian Hockmann <
> >> >> f...@florian-hockmann.de>
> >> >> > wrote:
> >> >> >
> >> >> > > We currently use this to push the package:
> >> >> > >
> >> >> > > ${nugetExe} push Gremlin.Net/bin/Gremlin.Net.*.nupkg
> >> >> > >
> >> >> > > which pushes all NuGet packages starting with Gremlin.Net. You
> >> >> probably
> >> >> > > also had the package for version 3.4.0-rc2 in that directory. So,
> >> >> > > nuget.exe tried to push that version again which isn't allowed by
> >> >> NuGet
> >> >> > > as packages are immutable for a given version.
> >> >> > >
> >> >> > > I guess we should specify the exact version here instead to avoid
> >> >> these
> >> >> > > problems in the future. Otherwise we could push development
> >> versions
> >> >> to
> >> >> > > nuget.org by accident. I probably implemented it like this at
> >> first
> >> >> > > because I assumed that mvn
Re: code freeze 3.2.10/3.3.4
If you're going to reopen tp32, then I'll retarget
https://github.com/apache/tinkerpop/pull/969
Robert Dale
On Fri, Oct 26, 2018 at 7:56 AM Robert Dale wrote:
> So to answer your earlier question on security fixes, the driver should be
> our security policy ;-)
>
> For example, if tp32 is not officially closed and accepts bug fixes, and
> given "security problems are just bugs" [1], then tp32 should get
> security-related bug fixes.
>
> We can use CVSS [2] to score vulnerabilities. They even have a handy-dandy
> calculator [3].
>
> The release trigger should also be in the security policy. It could be
> based on the CVSS score:
> <5, next scheduled release
> <7, within 30 days
> <8, within 2 weeks
> <9, within 1 week
> 9+, asap
>
> Or we just keep it simple, release next cycle unless someone can provide a
> proof of concept or just feels strongly otherwise.
>
> For example, I don't think TINKERPOP-2068 [4] is critical because our
> serializers handle only explicitly listed types. Nothing is blindly
> delegated to Jackson. No need for an emergency release. Someone can confirm.
>
> 1. https://lkml.org/lkml/2017/11/17/767
> 2. https://www.first.org/cvss/
> 3. https://www.first.org/cvss/calculator/3.0
> 4. https://issues.apache.org/jira/browse/TINKERPOP-2068
>
> Robert Dale
>
>
> On Fri, Oct 26, 2018 at 7:02 AM Stephen Mallette
> wrote:
>
>> tp32...
>>
>> i started thinking that we could keep a JIRA ticket open that had a list
>> of
>> bugs we might backport to tp32 should we have some triggering event,
>> buti dunno. maybe we go with a first step at this and re-open the
>> branch but just ship security+bug fixes at it and not try to wait for a
>> triggering event for release. i would expect the CHANGELOG for 3.2.11 to
>> be
>> really small if we do this right. please let me know if there are any
>> concerns, otherwise we'll start heading down this route and i'll re-open
>> the branch on Monday.
>>
>> On Mon, Oct 22, 2018 at 11:42 AM Stephen Mallette
>> wrote:
>>
>> > there's always going to be those kinds of things though right? can we
>> get
>> > away with doing stuff to tp32 only when there is some specific demand
>> for a
>> > 3.2.11. like, that fix on its own doesn't feel like something we'd
>> trigger
>> > a release overor would we?
>> >
>> > On Sat, Oct 20, 2018 at 9:27 AM Robert Dale wrote:
>> >
>> >> You don't want to put
>> >> https://issues.apache.org/jira/browse/TINKERPOP-2068
>> >> on tp32?
>> >>
>> >> Robert Dale
>> >>
>> >>
>> >> On Fri, Oct 19, 2018 at 6:03 PM Stephen Mallette > >
>> >> wrote:
>> >>
>> >> > > I created a ticket to track this and I can probably take care of
>> it
>> >> next
>> >> > week
>> >> >
>> >> > that makes sense, thank you.
>> >> >
>> >> > separately, code freeze is now lifted on tp33 - i've bumped to
>> >> > 3.3.5-SNAPSHOT, published initial docs/artifacts and all is good to
>> go.
>> >> > I've left tp32 on 3.2.10 until we decide to actually do something on
>> >> that
>> >> > branch. For now, we'll just say we're done there as we discussed
>> >> > elsethread.
>> >> >
>> >> > kuppitz, feel free to fire up the dead branch cleanup email. i wonder
>> >> if it
>> >> > will be more convenient to delete branches as we go now that we have
>> the
>> >> > github UI available to us. might be good to just hit the "delete
>> branch"
>> >> > button right when we hit the merge one.
>> >> >
>> >> > i will announce the releases on monday morning EST time.
>> >> >
>> >> >
>> >> >
>> >> > On Fri, Oct 19, 2018 at 5:04 PM Florian Hockmann <
>> >> f...@florian-hockmann.de>
>> >> > wrote:
>> >> >
>> >> > > We currently use this to push the package:
>> >> > >
>> >> > > ${nugetExe} push Gremlin.Net/bin/Gremlin.Net.*.nupkg
>> >> > >
>> >> > > which pushes all NuGet packages starting with Gremlin.Net. You
>> >> probably
>> >> > > also had the package for version 3.4.0-rc2 in that directory. So,
>> >> > > nuget.exe tried to push that version again which isn't allowed by
>> >> NuGet
>> >> > > as packages are immutable for a given version.
>> >> > >
>> >> > > I guess we should specify the exact version here instead to avoid
>> >> these
>> >> > > problems in the future. Otherwise we could push development
>> versions
>> >> to
>> >> > > nuget.org by accident. I probably implemented it like this at
>> first
>> >> > > because I assumed that mvn clean would always remove older packages
>> >> > > which seems to be not the case here.
>> >> > >
>> >> > > Anyway, I created a ticket to track this and I can probably take
>> care
>> >> of
>> >> > > it next week:
>> >> > >
>> >> > > https://issues.apache.org/jira/browse/TINKERPOP-2074
>> >> > >
>> >> > >
>> >> > > Am 19.10.2018 um 21:16 schrieb Stephen Mallette:
>> >> > > > Florian, any idea what's going on with this error when i deployed
>> >> > 3.3.4:
>> >> > > >
>> >> > > > main:
>> >> > > > [echo] nuget.exe already downloaded.
>> >> > > > [exec] Pushing Gremlin.Net.3.3.4.nupkg to '
>> >> > > >
Re: code freeze 3.2.10/3.3.4
So to answer your earlier question on security fixes, the driver should be
our security policy ;-)
For example, if tp32 is not officially closed and accepts bug fixes, and
given "security problems are just bugs" [1], then tp32 should get
security-related bug fixes.
We can use CVSS [2] to score vulnerabilities. They even have a handy-dandy
calculator [3].
The release trigger should also be in the security policy. It could be
based on the CVSS score:
<5, next scheduled release
<7, within 30 days
<8, within 2 weeks
<9, within 1 week
9+, asap
Or we just keep it simple, release next cycle unless someone can provide a
proof of concept or just feels strongly otherwise.
For example, I don't think TINKERPOP-2068 [4] is critical because our
serializers handle only explicitly listed types. Nothing is blindly
delegated to Jackson. No need for an emergency release. Someone can confirm.
1. https://lkml.org/lkml/2017/11/17/767
2. https://www.first.org/cvss/
3. https://www.first.org/cvss/calculator/3.0
4. https://issues.apache.org/jira/browse/TINKERPOP-2068
Robert Dale
On Fri, Oct 26, 2018 at 7:02 AM Stephen Mallette
wrote:
> tp32...
>
> i started thinking that we could keep a JIRA ticket open that had a list of
> bugs we might backport to tp32 should we have some triggering event,
> buti dunno. maybe we go with a first step at this and re-open the
> branch but just ship security+bug fixes at it and not try to wait for a
> triggering event for release. i would expect the CHANGELOG for 3.2.11 to be
> really small if we do this right. please let me know if there are any
> concerns, otherwise we'll start heading down this route and i'll re-open
> the branch on Monday.
>
> On Mon, Oct 22, 2018 at 11:42 AM Stephen Mallette
> wrote:
>
> > there's always going to be those kinds of things though right? can we get
> > away with doing stuff to tp32 only when there is some specific demand
> for a
> > 3.2.11. like, that fix on its own doesn't feel like something we'd
> trigger
> > a release overor would we?
> >
> > On Sat, Oct 20, 2018 at 9:27 AM Robert Dale wrote:
> >
> >> You don't want to put
> >> https://issues.apache.org/jira/browse/TINKERPOP-2068
> >> on tp32?
> >>
> >> Robert Dale
> >>
> >>
> >> On Fri, Oct 19, 2018 at 6:03 PM Stephen Mallette
> >> wrote:
> >>
> >> > > I created a ticket to track this and I can probably take care of it
> >> next
> >> > week
> >> >
> >> > that makes sense, thank you.
> >> >
> >> > separately, code freeze is now lifted on tp33 - i've bumped to
> >> > 3.3.5-SNAPSHOT, published initial docs/artifacts and all is good to
> go.
> >> > I've left tp32 on 3.2.10 until we decide to actually do something on
> >> that
> >> > branch. For now, we'll just say we're done there as we discussed
> >> > elsethread.
> >> >
> >> > kuppitz, feel free to fire up the dead branch cleanup email. i wonder
> >> if it
> >> > will be more convenient to delete branches as we go now that we have
> the
> >> > github UI available to us. might be good to just hit the "delete
> branch"
> >> > button right when we hit the merge one.
> >> >
> >> > i will announce the releases on monday morning EST time.
> >> >
> >> >
> >> >
> >> > On Fri, Oct 19, 2018 at 5:04 PM Florian Hockmann <
> >> f...@florian-hockmann.de>
> >> > wrote:
> >> >
> >> > > We currently use this to push the package:
> >> > >
> >> > > ${nugetExe} push Gremlin.Net/bin/Gremlin.Net.*.nupkg
> >> > >
> >> > > which pushes all NuGet packages starting with Gremlin.Net. You
> >> probably
> >> > > also had the package for version 3.4.0-rc2 in that directory. So,
> >> > > nuget.exe tried to push that version again which isn't allowed by
> >> NuGet
> >> > > as packages are immutable for a given version.
> >> > >
> >> > > I guess we should specify the exact version here instead to avoid
> >> these
> >> > > problems in the future. Otherwise we could push development versions
> >> to
> >> > > nuget.org by accident. I probably implemented it like this at first
> >> > > because I assumed that mvn clean would always remove older packages
> >> > > which seems to be not the case here.
> >> > >
> >> > > Anyway, I created a ticket to track this and I can probably take
> care
> >> of
> >> > > it next week:
> >> > >
> >> > > https://issues.apache.org/jira/browse/TINKERPOP-2074
> >> > >
> >> > >
> >> > > Am 19.10.2018 um 21:16 schrieb Stephen Mallette:
> >> > > > Florian, any idea what's going on with this error when i deployed
> >> > 3.3.4:
> >> > > >
> >> > > > main:
> >> > > > [echo] nuget.exe already downloaded.
> >> > > > [exec] Pushing Gremlin.Net.3.3.4.nupkg to '
> >> > > > https://www.nuget.org/api/v2/package'...
> >> > > > [exec] PUT https://www.nuget.org/api/v2/package/
> >> > > > [exec] Created https://www.nuget.org/api/v2/package/
> 1362ms
> >> > > > [exec] Your package was pushed.
> >> > > > [exec] Pushing Gremlin.Net.Template.3.3.4.nupkg to '
> >> > > > https://www.nuget.org/api/v2/package'...
> >> > > >
[jira] [Commented] (TINKERPOP-2027) Add a Typescript definitions file to the project
[ https://issues.apache.org/jira/browse/TINKERPOP-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16665039#comment-16665039 ] Jorge Bay commented on TINKERPOP-2027: -- That sounds good! It would be the same approach as the template files in https://github.com/apache/tinkerpop/tree/3.3.4/gremlin-javascript/glv/ > Add a Typescript definitions file to the project > > > Key: TINKERPOP-2027 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2027 > Project: TinkerPop > Issue Type: Improvement > Components: javascript >Affects Versions: 3.3.3, 3.2.9 >Reporter: Matthew Allen >Priority: Major > > For those using Typescript it would be great to provide a type definition > file for the glv. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: code freeze 3.2.10/3.3.4
tp32...
i started thinking that we could keep a JIRA ticket open that had a list of
bugs we might backport to tp32 should we have some triggering event,
buti dunno. maybe we go with a first step at this and re-open the
branch but just ship security+bug fixes at it and not try to wait for a
triggering event for release. i would expect the CHANGELOG for 3.2.11 to be
really small if we do this right. please let me know if there are any
concerns, otherwise we'll start heading down this route and i'll re-open
the branch on Monday.
On Mon, Oct 22, 2018 at 11:42 AM Stephen Mallette
wrote:
> there's always going to be those kinds of things though right? can we get
> away with doing stuff to tp32 only when there is some specific demand for a
> 3.2.11. like, that fix on its own doesn't feel like something we'd trigger
> a release overor would we?
>
> On Sat, Oct 20, 2018 at 9:27 AM Robert Dale wrote:
>
>> You don't want to put
>> https://issues.apache.org/jira/browse/TINKERPOP-2068
>> on tp32?
>>
>> Robert Dale
>>
>>
>> On Fri, Oct 19, 2018 at 6:03 PM Stephen Mallette
>> wrote:
>>
>> > > I created a ticket to track this and I can probably take care of it
>> next
>> > week
>> >
>> > that makes sense, thank you.
>> >
>> > separately, code freeze is now lifted on tp33 - i've bumped to
>> > 3.3.5-SNAPSHOT, published initial docs/artifacts and all is good to go.
>> > I've left tp32 on 3.2.10 until we decide to actually do something on
>> that
>> > branch. For now, we'll just say we're done there as we discussed
>> > elsethread.
>> >
>> > kuppitz, feel free to fire up the dead branch cleanup email. i wonder
>> if it
>> > will be more convenient to delete branches as we go now that we have the
>> > github UI available to us. might be good to just hit the "delete branch"
>> > button right when we hit the merge one.
>> >
>> > i will announce the releases on monday morning EST time.
>> >
>> >
>> >
>> > On Fri, Oct 19, 2018 at 5:04 PM Florian Hockmann <
>> f...@florian-hockmann.de>
>> > wrote:
>> >
>> > > We currently use this to push the package:
>> > >
>> > > ${nugetExe} push Gremlin.Net/bin/Gremlin.Net.*.nupkg
>> > >
>> > > which pushes all NuGet packages starting with Gremlin.Net. You
>> probably
>> > > also had the package for version 3.4.0-rc2 in that directory. So,
>> > > nuget.exe tried to push that version again which isn't allowed by
>> NuGet
>> > > as packages are immutable for a given version.
>> > >
>> > > I guess we should specify the exact version here instead to avoid
>> these
>> > > problems in the future. Otherwise we could push development versions
>> to
>> > > nuget.org by accident. I probably implemented it like this at first
>> > > because I assumed that mvn clean would always remove older packages
>> > > which seems to be not the case here.
>> > >
>> > > Anyway, I created a ticket to track this and I can probably take care
>> of
>> > > it next week:
>> > >
>> > > https://issues.apache.org/jira/browse/TINKERPOP-2074
>> > >
>> > >
>> > > Am 19.10.2018 um 21:16 schrieb Stephen Mallette:
>> > > > Florian, any idea what's going on with this error when i deployed
>> > 3.3.4:
>> > > >
>> > > > main:
>> > > > [echo] nuget.exe already downloaded.
>> > > > [exec] Pushing Gremlin.Net.3.3.4.nupkg to '
>> > > > https://www.nuget.org/api/v2/package'...
>> > > > [exec] PUT https://www.nuget.org/api/v2/package/
>> > > > [exec] Created https://www.nuget.org/api/v2/package/ 1362ms
>> > > > [exec] Your package was pushed.
>> > > > [exec] Pushing Gremlin.Net.Template.3.3.4.nupkg to '
>> > > > https://www.nuget.org/api/v2/package'...
>> > > > [exec] PUT https://www.nuget.org/api/v2/package/
>> > > > [exec] Created https://www.nuget.org/api/v2/package/ 11405ms
>> > > > [exec] Your package was pushed.
>> > > > [exec] Pushing Gremlin.Net.Template.3.4.0-rc2.nupkg to '
>> > > > https://www.nuget.org/api/v2/package'...
>> > > > [exec] PUT https://www.nuget.org/api/v2/package/
>> > > > [exec] Conflict https://www.nuget.org/api/v2/package/ 365ms
>> > > > [exec] 409 (A package with ID 'Gremlin.Net.Template' and
>> version
>> > > > '3.4.0-rc2' already exists and cannot be modified.)
>> > > >
>> > > >
>> > > > why is it trying to push the 3.4.0 line? looks like the error
>> didn't
>> > > > matter as the other two published fine, but let's fix the error if
>> we
>> > > > can...
>> > > >
>> > > > On Fri, Oct 12, 2018 at 7:27 PM Stephen Mallette <
>> spmalle...@gmail.com
>> > >
>> > > > wrote:
>> > > >
>> > > >> Robert Dale is without power so I pushed the 3.2.10-SNAPSHOT
>> artifacts
>> > > and
>> > > >> docs too:
>> > > >>
>> > > >> http://tinkerpop.apache.org/docs/3.2.10-SNAPSHOT/
>> > > >>
>> > > >>
>> > > >>
>> > > >> On Fri, Oct 12, 2018 at 8:22 AM Stephen Mallette <
>> > spmalle...@gmail.com>
>> > > >> wrote:
>> > > >>
>> > > >>> I just published final 3.3.4-SNAPSHOT artifacts and docs:
>> > > >>>
>> > > >>>
[GitHub] [tinkerpop] jorgebay commented on issue #971: TINKERPOP-2062 added Traversal class to CoreImports
sgtm, VOTE +1 [ Full content available at: https://github.com/apache/tinkerpop/pull/971 ] This message was relayed via gitbox.apache.org for dev@tinkerpop.apache.org
[jira] [Commented] (TINKERPOP-2027) Add a Typescript definitions file to the project
[
https://issues.apache.org/jira/browse/TINKERPOP-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16664796#comment-16664796
]
Jorge Bay commented on TINKERPOP-2027:
--
I think it would be best for the definition files to live inside this project,
using a {{index.ts.d}} file:
[http://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html]
Most of the GLV is generated using a groovy script:
[https://github.com/apache/tinkerpop/blob/3.3.4/gremlin-javascript/glv/generate.groovy]
, specifically the [process
API|http://tinkerpop.apache.org/docs/current/reference/#the-graph-process]
(traversal, traversal source, enums, ...).
The structure API ({{Vertex}}, {{Edge}}, properties and other representations)
and driver API ({{RemoteConnection}}) are not generated but changes to that API
are rare.
We can use the groovy script to partially generate the index definition file
and manually code the other ones.
> Add a Typescript definitions file to the project
>
>
> Key: TINKERPOP-2027
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2027
> Project: TinkerPop
> Issue Type: Improvement
> Components: javascript
>Affects Versions: 3.3.3, 3.2.9
>Reporter: Matthew Allen
>Priority: Major
>
> For those using Typescript it would be great to provide a type definition
> file for the glv.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (TINKERPOP-2027) Add a Typescript definitions file to the project
[ https://issues.apache.org/jira/browse/TINKERPOP-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16664702#comment-16664702 ] Matthew Allen edited comment on TINKERPOP-2027 at 10/26/18 6:00 AM: [~spmallette] [~jorgebg] Having had a look at this it looks like there will always be some degree of maintenance required for a typings file due to the non-generated classes in the project. At the moment there doesn't appear to be an automated way to get the type information from JS files, whether from doc comments or any other means. We could generate the GLV side from the Java code but it would then require the other project classes to be added and maintained. I would be happy to generate and edit typings files, as I have time to, and submit these to Definitely Typed after each release, unless you think the project can manage maintaining the types file? was (Author: mattallenuk): [~spmallette] [~jorgebg] Having had a look at this it looks like there will always be some degree of maintenance required for a typings file due to the non-generated classes in the project. At the moment there doesn't appear to be an automated way to get the type information from JS files, whether from doc comments or any other means. We could generate the GLV side from the Java code but it would then require the other project classes to be added and maintained. I would be happy to generate and edit typings files, as I have time to, and submit these to Definitely Typed after each release, unless you think the project can manage maintaining the files? > Add a Typescript definitions file to the project > > > Key: TINKERPOP-2027 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2027 > Project: TinkerPop > Issue Type: Improvement > Components: javascript >Affects Versions: 3.3.3, 3.2.9 >Reporter: Matthew Allen >Priority: Major > > For those using Typescript it would be great to provide a type definition > file for the glv. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2027) Add a Typescript definitions file to the project
[ https://issues.apache.org/jira/browse/TINKERPOP-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16664702#comment-16664702 ] Matthew Allen commented on TINKERPOP-2027: -- [~spmallette] [~jorgebg] Having had a look at this it looks like there will always be some degree of maintenance required for a typings file due to the non-generated classes in the project. At the moment there doesn't appear to be an automated way to get the type information from JS files, whether from doc comments or any other means. We could generate the GLV side from the Java code but it would then require the other project classes to be added and maintained. I would be happy to generate and edit typings files, as I have time to, and submit these to Definitely Typed after each release, unless you think the project can manage maintaining the files? > Add a Typescript definitions file to the project > > > Key: TINKERPOP-2027 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2027 > Project: TinkerPop > Issue Type: Improvement > Components: javascript >Affects Versions: 3.3.3, 3.2.9 >Reporter: Matthew Allen >Priority: Major > > For those using Typescript it would be great to provide a type definition > file for the glv. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
