Sounds good, we can evaluate the possibilities per each non-JVM language GLV.
In the case of C#, there is now a new runtime and build tools ".NET Core" that runs in any major platform, that could be suitable for building and running the tests of the GLV. Thanks, Jorge On Fri, Nov 11, 2016 at 2:44 PM, Stephen Mallette <[email protected]> wrote: > Thanks for clarifying. > > I guess I would say that it would be ideal if we had the code in TinkerPop, > as TinkerPop should be responsible for the interfaces of a GLV. Of course, > I'd acknowledge the technical challenges of doing that, plus I'd further > note the lack of a testing framework for non-JVM languages, which has been > part of other discussions. I came up with a good way to get gremlin-python > worked into the standard TinkerPop build. I suspect the same pattern would > work for gremlin-js. The key to those is the .glv file that tells maven > whether to even bother trying to build it or not. In this way, the project > stays generally buildable with mvn clean install, even if your environment > isn't setup to handle python (for example). So, if you aren't setup to > build gremlin-js in your environment, just omit the .glv file and focus on > the rest of the project. > > Does that pattern make sense for gremlin-csharp? i sorta think so. If I'm > on linux without NET then it would simply be ignored. If i get linux > running with mono (i assume that is still a thing) then i add the .glv file > and presumably we can get maven to automate a csharp build somehow??? > > I think the short answer from my perspective is that I'm not against having > these non-JVM GLVs be in TinkerPop so long as we have a good means for > building, testing, and deploying. If we find having all these GLVs in our > current "JVM" repo doesn't work too well, we can also request additional > git resources from Apache Infra. As I generally tend to handle releases, my > preference would be to have one repo with one deploy cycle where everything > is versioned at the same time. > > > On Fri, Nov 11, 2016 at 8:25 AM, Jorge Bay Gondra < > [email protected] > > wrote: > > > For specification I mean a formal documentation detailing the GLV API > for a > > certain language, including naming convention, return types, limitations > > and side effects that can be versioned along with Apache TinkerPop. > > > > With that specification as part of the TK documentation, an implementer > > could state "Supports Apache TinkerPop C# GLV 3.3" > > > > On Fri, Nov 11, 2016 at 1:03 PM, Stephen Mallette <[email protected]> > > wrote: > > > > > Could you expand on what you mean by a "GLV spec" that you mention in > > item > > > A? > > > > > > On Fri, Nov 11, 2016 at 6:38 AM, Jorge Bay Gondra < > > > [email protected] > > > > wrote: > > > > > > > Hi, > > > > After the [Javascript GLV][1], I'm thinking of creating a GLV for C#, > > > but I > > > > don't know if a GLV for a language like C# or C++ with no JVM support > > > > (decent JVM language implementation nor scripting support) belongs in > > the > > > > TinkerPop repository as it won't be able to easily integrate with the > > > rest > > > > of the projects. > > > > > > > > A) Should we include only a GLV spec for those languages? > > > > B) Should we create a full GLV inside the TK repo, adding the build > > tools > > > > for those runtimes as dependencies to run the tests ? > > > > > > > > Thanks, > > > > Jorge > > > > > > > > [1]: https://issues.apache.org/jira/browse/TINKERPOP-1489 > > > > > > > > > >
