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

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

Github user spmallette commented on the issue:

    https://github.com/apache/tinkerpop/pull/600
  
    > Do you want to figure out the test framework before merging in new GLVs 
or can we merge it in and then adopt the framework later on? 
    
    My inclination is to not be too hasty - note that the JS glv has been 
sitting for a while at #450 - and to use this opportunity to figure out what we 
need to do to properly bring both of these in.  One thing that may happen is 
that we merge both the PRs to a feature branch of this repo that TinkerPop can 
maintain/rebase/etc. You (and others) could in turn submit PRs against that 
until it's ready to merge to the release branches. This approach has the 
advantage that we can rig up the platform independent test suite around the 
existing project and the new GLVs.


> 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
>
> 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)

Reply via email to