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

Florian Hockmann commented on TINKERPOP-1552:
---------------------------------------------

The good thing is that we can still change the structure later on because we 
only use it internally to generate the GLV.

I noticed that you added a comment to all generated files that states the fact 
that it was generated to prevent someone from modifying it by hand. While I 
generally think that such a comment should be there, I wouldn't format it as an 
XML documentation comment as those comments are meant to be read by users. When 
you hover over the class in your IDE than it will show you this comment. Since 
this information is only important for developers we can just include it as a 
normal comment instead. Then we can also use the {{summary}} element for a 
short description of the class itself.

> 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.4.14#64029)

Reply via email to