I don't know how it would work, but I've been imagining something that uses cucumber somehow. Cypher uses it for it's language agnostic testing in their Technology Compatibility Kit:
https://github.com/opencypher/openCypher/tree/master/tck Again, not sure how cucumber (or whatever we use) would be setup to help us out, but there should be something central to TinkerPop that a GLV can run some tests against to say "This GLV is good". On Wed, May 31, 2017 at 7:20 AM, Jorge Bay Gondra <jorge.gon...@datastax.com > wrote: > Hi, > I'm not sure I understand what you mean by "The method for testing GLVs is > not language agnostic"? > It would be nice to have a reusable test suite to make a GLV pass through > but it would involve a communication mechanism between 2 different runtimes > (ie: jvm and dotnet) that could be very hard to maintain. > I think that having unit and integration tests on the GLV implementation > should be enough. Which functionality and the level of coverage should be > defined upfront, though. > > Jorge > > On Thu, May 18, 2017 at 7:01 PM, Stephen Mallette <spmalle...@gmail.com> > wrote: > > > So i took a few minutes to deal with those GLV pull requests that have > been > > hanging out there. I did things a little differently than I had described > > in this thread. i created TINKERPOP-1489 branch for js work and > > TINKERPOP-1552 for c# work. both branches extend from tp32-glv. in this > > way, the GLVs are not coupled together to be forced to be merged > together. > > they can be developed at their own pace. note that tp32-glv can house > > changes useful to both of these GLVs (stuff like the revised testing > > framework). > > > > > > > > On Mon, Apr 17, 2017 at 3:29 PM, Stephen Mallette <spmalle...@gmail.com> > > wrote: > > > > > Not sure if you remember all the discussions we've had (would have to > dig > > > through the mailing list to find them), but GLVs are meant to be > > TinkerPop > > > maintained. There were a number of reasons for this, but basically GLVs > > are > > > too important to TinkerPop's spread and adoption to be left to > > > third-parties. > > > > > > On Mon, Apr 17, 2017 at 3:12 PM, Robert Dale <robd...@gmail.com> > wrote: > > > > > >> I think there's less risk and work having GLVs linked and listed on > the > > >> Query Languages [Providers] pages (enhancement: specify which are > > >> developed > > >> by Apache TinkerPop or third-party/community). The risk being that > the > > >> maintainer disappears and no one else has the skill/time to move it > > >> forward. Seems to have worked so far. What is the motivation to pull > > >> these > > >> in now? > > >> > > >> Robert Dale > > >> > > >> On Mon, Apr 17, 2017 at 1:06 PM, Stephen Mallette < > spmalle...@gmail.com > > > > > >> wrote: > > >> > > >> > I'm not sure if it's been generally noticed, but Florian Hockmann > > >> recently > > >> > produced: > > >> > > > >> > https://github.com/apache/tinkerpop/pull/600 > > >> > > > >> > which gives TinkerPop the start of a .NET based GLV. We also have a > > long > > >> > standing PR for the start of a JS GLV with: > > >> > > > >> > https://github.com/apache/tinkerpop/pull/450 > > >> > > > >> > In evaluating both of these PRs, I'm concerned about several things: > > >> > > > >> > 1. The method for testing GLVs is not language agnostic (our current > > >> > process is only good on the JVM) > > >> > 2. The method for serialization is in a weird place because GraphSON > > 2.0 > > >> > still has some limitations which need to be addressed which might > lead > > >> to a > > >> > better more unified approach to how TinkerPop does serialization. > > >> > > > >> > I think that it's worth addressing these issues prior to making > these > > >> two > > >> > PRs part of any release branch. Unfortunately neither concern has a > > >> quick > > >> > fix. I'm thinking about merging both of those PRs to a GLV feature > > >> branch > > >> > based on tp32 then tinkering with them from there. They are large > > >> bodies of > > >> > work and would probably be easier to evaluate and for others to > > >> contribute > > >> > to if there was a common place to work on them. From there we can > > think > > >> on > > >> > the two issues I listed above on the release branches and just > rebase > > >> GLV > > >> > feature branch on that as needed. > > >> > > > >> > Any concerns about taking this approach? Are there other issues > > involved > > >> > with bringing in GLVs that should be listed? Other ways to deal with > > >> this? > > >> > > > >> > Thanks, > > >> > > > >> > Stephen > > >> > > > >> > > > > > > > > >
