You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by "stephen mallette (JIRA)" <ji...@apache.org> on 2017/07/18 13:12:02 UTC

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

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

stephen mallette closed TINKERPOP-1552.
---------------------------------------
       Resolution: Done
    Fix Version/s: 3.2.6

This is "done' in the sense that we have a basic implementation of Gremlin .NET, but it's still lacking some important bits that will prevent us from doing a full release. Those issues will be handled as separate issues as it was getting harder and harder to manage the feature branching we were doing given divergence between tp32 and master. In any case, new JIRA issues should be popping up to get Gremlin .NET ready for full production ready release.

> 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
>             Fix For: 3.2.6
>
>
> 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.4.14#64029)