yeah - i actually thought about "gremlin-tools" and almost wondered if we
shouldn't do:
gremlin-tools
+-gremlin-benchmarks
+-gremlin-coverage
for 3.3.0. The added flexibility to have independent poms for these things
might turn out useful. I sorta like that idea.
On Sat, Oct 8, 2016 at 10:47 AM,
Adding coverage to gremlin-benchmark sounds good to me. If we come up with
any other dev specific tooling that we'd like to add, maybe it would make
sense
to just rename gremlin-benchmark to something like gremlin-tools or
gremlin-dev.
--Ted
On Fri, Oct 7, 2016 at 5:20 PM, Stephen Mallette
wrot
Thought I'd keep this thread warm a bit. If you've built the TinkerPop repo
recently, you would realize it's taking a really long time these days to
get a simple `mvn clean install` completed. We've produced tons of tests
that are adding to build times and I think that while we have lots of
tests,
I think these are the ones that contain logic and are dynamically sorta
driven:
ElementFeatures.willAllowId(Object)
VertexPropertyFeatures.willAllowId(Object)
VertexFeatures.getCardinality(String)
I was thinking that some graphs might return static values for these in
which case caching would wor
Nice discussion thread, Stephen. I've tinkered around minimally with
writing a graph implementation, so hopefully we'll get more feedback from
others. From what I have done, +1 on killing @OptOut test annotations. They
seem out of place on the Graph impl class.
You mentioned "there is at least one
I've spent the middle portion of the day reviewing our test infrastructure
and related open tickets and have some ideas to make some things better. I
titled this post for 3.3.0, but, in truth, I'm not sure what must be 3.3.0
and what might yet be useful and good for 3.2.x. I'm also using this email
