[
https://issues.apache.org/jira/browse/TINKERPOP-1552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16044207#comment-16044207
]
Florian Hockmann commented on TINKERPOP-1552:
---------------------------------------------
I would suggest that we review each others pull requests before they are
getting merged in. That makes it easier to discuss the changes and maybe fix
issues found during review. It also improves the confidence we have in that
branch regarding publishing of pre-release versions and the final review when
the branch is merged into a release branch.
{quote}
1. I couldn't make it because of TraverserAggregator and TraverserReader
classes.
{quote}
Ok, I see the problem. The deserializing only gets its type information from
the GraphSON which doesn't include the type of the traversed object. So the
{{TraverserReader}} can't create a {{Traverser}} object when that has a generic
type parameter. In Java that seems to be no problem as you can do something
like: {{return new DefaultRemoteTraverser<>(...)}}.
> 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)
