Re: Site organization, including links to recipes and various tutorials

[Stephen Mallette]

It took me a a while but I figured out how to inject the project version
from the maven pom directly into javadoc. I guess the approach ended up
being pretty simple and just uses filtering with the maven resources
plugin, but it seemed like a hacky way to implement it. I thought for sure
there would be something built directly into the maven javadoc plugin, but
sadly I could come up with no such solution. Anyway, this change lets us to
better cross-reference our javadoc with our reference docs which is
something we've ignored a bit (mostly because we've never had this nice way
to link to those documents without the "version variable").

I've started to complete the javadoc on GraphTraversal and cross-reference
that to the reference docs with @see tags. If you ever feel the need to
link from javadoc to the Reference Docs you can see the pattern that I've
started in GraphTraversal at this point on the tp32/mastter branch. I still
have a little ways to go with GraphTraversal to get that all javadoc'd - i
suspect I might finish a rough pass at it all by end of day tomorrow.

On Thu, Feb 9, 2017 at 1:28 PM, Stephen Mallette 
wrote:

> One idea I've had is to better cross reference our docs. More links
> between the different documents we have would be helpful. For example, when
> we mention a particular step somewhere in a recpie or tutorial, do a link
> to the step in the reference docs. For each step in the reference docs have
> a "See also" section that links to other areas in tutorials, recipes, etc.
> where that step is used. I think that would get people more aware of what's
> out there and would give them the chance to read more of what we have
> available.  It does represent a fair bit of work though.
>
> I don't doubt that we couldn't improve the web site. Would be nice to hear
> if anyone has specific proposals in that area.
>
> On Thu, Feb 9, 2017 at 1:16 PM, Jeremy Hanna 
> wrote:
>
>> I’ve given the links to the recipes page and the getting started tutorial
>> (for instance) to people and they’ve said, “hey wow, this is great stuff.
>> I wish I had this like last week!”  I see that the only place those are
>> currently is the TinkerPop home page.  So I wondered what a better place
>> for those would be.  Should we put them near the top of the docs page as
>> well?  Any thoughts on perhaps reorganizing the home page?
>>
>> Thanks,
>>
>> Jeremy
>
>
>

[jira] [Commented] (TINKERPOP-1554) has(propertyKey) should have a corresponding step in Gremlin-Java.

[ASF GitHub Bot (JIRA)]

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

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

GitHub user okram opened a pull request:

https://github.com/apache/tinkerpop/pull/560

TINKERPOP-1554: has(propertyKey) should have a corresponding step in 
Gremlin-Java.

https://issues.apache.org/jira/browse/TINKERPOP-1554

Currently `has('name')` compiles to `filter(values('name'))`. Its a used 
enough "step" that it should really have its own direct step compilation for 
efficiency, understability, and ease of strategy manipulation.

VOTE +1.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1554

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/560.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #560


commit 6fa8aa6bb0504ba5e3408a0fb7a5df31b26912ac
Author: Marko A. Rodriguez 
Date:   2017-02-16T20:13:24Z

added HasPropertyStep so has(key) no longer compiles to 
filter(values(key)). Its a used enough step that it should really have its own 
direct step compilation.




> has(propertyKey) should have a corresponding step in Gremlin-Java.
> --
>
> Key: TINKERPOP-1554
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1554
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> Currently {{has('name')}} compiles to {{filter(values('name'))}}. This is bad 
> for a few reasons:
> 1. Its slower than a direct step.
> 2. Its nested traversals which increases reasoning time of strategies.
> 3. Its not clear from bytecode what it going on.
> I propose:
> {code}
> public class HasPropertyStep implements FilterStep {
>   private String propertyKey;
>   public boolean filter(final Traverser.Admin traverser) {
> return traverser.get().properties(propertyKey).hasNext();
>   }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] tinkerpop pull request #560: TINKERPOP-1554: has(propertyKey) should have a ...

[okram]

GitHub user okram opened a pull request:

https://github.com/apache/tinkerpop/pull/560

TINKERPOP-1554: has(propertyKey) should have a corresponding step in 
Gremlin-Java.

https://issues.apache.org/jira/browse/TINKERPOP-1554

Currently `has('name')` compiles to `filter(values('name'))`. Its a used 
enough "step" that it should really have its own direct step compilation for 
efficiency, understability, and ease of strategy manipulation.

VOTE +1.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/apache/tinkerpop TINKERPOP-1554

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/tinkerpop/pull/560.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #560


commit 6fa8aa6bb0504ba5e3408a0fb7a5df31b26912ac
Author: Marko A. Rodriguez 
Date:   2017-02-16T20:13:24Z

added HasPropertyStep so has(key) no longer compiles to 
filter(values(key)). Its a used enough step that it should really have its own 
direct step compilation.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Assigned] (TINKERPOP-1615) Doing a step many times can lead to unforeseen problems with the RepeatUnrollStrategy

[Daniel Kuppitz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel Kuppitz reassigned TINKERPOP-1615:
-

Assignee: Daniel Kuppitz

> Doing a step many times can lead to unforeseen problems with the 
> RepeatUnrollStrategy
> -
>
> Key: TINKERPOP-1615
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1615
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Jeremy Hanna
>Assignee: Daniel Kuppitz
>
> The following traversal comes back with an error that appears to be related 
> to the {{RepeatUnrollStrategy}}:
> {code}
> g.V().has('foo', 'id', 
> '4b200757-96e2-463a-a7a0-7b9b75d4dbd3').repeat(__.in('subfolder_of')).times(100).hasNext()
> {code}
> appears to either error out or take forever.  However if I do something like:
> {code}
> g.withoutStrategies(RepeatUnrollStrategy.class).V().has('foo', 'id', 
> '4b200757-96e2-463a-a7a0-7b9b75d4dbd3').repeat(__.in('subfolder_of')).times(100).hasNext()
> {code}
> it works subsecond.
> So something funky with {{RepeatUnrollStrategy}} is going on.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (TINKERPOP-1554) has(propertyKey) should have a corresponding step in Gremlin-Java.

[Marko A. Rodriguez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marko A. Rodriguez reassigned TINKERPOP-1554:
-

Assignee: Marko A. Rodriguez

> has(propertyKey) should have a corresponding step in Gremlin-Java.
> --
>
> Key: TINKERPOP-1554
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1554
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> Currently {{has('name')}} compiles to {{filter(values('name'))}}. This is bad 
> for a few reasons:
> 1. Its slower than a direct step.
> 2. Its nested traversals which increases reasoning time of strategies.
> 3. Its not clear from bytecode what it going on.
> I propose:
> {code}
> public class HasPropertyStep implements FilterStep {
>   private String propertyKey;
>   public boolean filter(final Traverser.Admin traverser) {
> return traverser.get().properties(propertyKey).hasNext();
>   }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (TINKERPOP-1614) Improve documentation for Graph.V() and Graph.E() on main docs page

[Marko A. Rodriguez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TINKERPOP-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marko A. Rodriguez reassigned TINKERPOP-1614:
-

Assignee: Daniel Kuppitz

> Improve documentation for Graph.V() and Graph.E() on main docs page
> ---
>
> Key: TINKERPOP-1614
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1614
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: documentation
>Reporter: Bob Briody
>Assignee: Daniel Kuppitz
>
> I was trying to help someone out on stack overflow recently: 
> http://stackoverflow.com/questions/41638792/dse-graph-get-all-edges-between-two-vertexes.
>  I was on the main TinkerPop3 Docs page looking for some introduction to 
> g.V() that would be good to copy/paste, but couldn't find anything. 
> It seems like there might be a stepping stone missing between "The Traversal" 
> and "Graph Traversal Steps" - a stepping stone about using V and E to 
> seed/start a Traversal.
> The use of IDs should also be discussed there as well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (TINKERPOP-1615) Doing a step many times can lead to unforeseen problems with the RepeatUnrollStrategy

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez commented on TINKERPOP-1615:
---

[~dkuppitz] Could you try and reproduce this in {{RepeatUnrollStrategyTest}}? 
If you can and can't fix it, send me the branch/ and I can finish it off.

> Doing a step many times can lead to unforeseen problems with the 
> RepeatUnrollStrategy
> -
>
> Key: TINKERPOP-1615
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1615
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.3
>Reporter: Jeremy Hanna
>
> The following traversal comes back with an error that appears to be related 
> to the {{RepeatUnrollStrategy}}:
> {code}
> g.V().has('foo', 'id', 
> '4b200757-96e2-463a-a7a0-7b9b75d4dbd3').repeat(__.in('subfolder_of')).times(100).hasNext()
> {code}
> appears to either error out or take forever.  However if I do something like:
> {code}
> g.withoutStrategies(RepeatUnrollStrategy.class).V().has('foo', 'id', 
> '4b200757-96e2-463a-a7a0-7b9b75d4dbd3').repeat(__.in('subfolder_of')).times(100).hasNext()
> {code}
> it works subsecond.
> So something funky with {{RepeatUnrollStrategy}} is going on.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (TINKERPOP-1627) LazyBarrierStrategy should not append an end barrier.

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/559


> LazyBarrierStrategy should not append an end barrier.
> -
>
> Key: TINKERPOP-1627
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1627
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.5
>
>
> {code}
> gremlin> g.V().out().explain()
> ==>Traversal Explanation
> ==
> Original Traversal [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex)]
> ConnectiveStrategy   [D]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex)]
> RangeByIsCountStrategy   [O]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex)]
> RepeatUnrollStrategy [O]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex)]
> MatchPredicateStrategy   [O]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex)]
> PathRetractionStrategy   [O]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex)]
> IncidentToAdjacentStrategy   [O]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex)]
> FilterRankingStrategy[O]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex)]
> InlineFilterStrategy [O]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex)]
> AdjacentToIncidentStrategy   [O]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex)]
> LazyBarrierStrategy  [O]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex), NoOpBarrierStep(2500)]
> TinkerGraphCountStrategy [P]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex), NoOpBarrierStep(2500)]
> TinkerGraphStepStrategy  [P]   [TinkerGraphStep(vertex,[]), 
> VertexStep(OUT,vertex), NoOpBarrierStep(2500)]
> ProfileStrategy  [F]   [TinkerGraphStep(vertex,[]), 
> VertexStep(OUT,vertex), NoOpBarrierStep(2500)]
> StandardVerificationStrategy [V]   [TinkerGraphStep(vertex,[]), 
> VertexStep(OUT,vertex), NoOpBarrierStep(2500)]
> Final Traversal[TinkerGraphStep(vertex,[]), 
> VertexStep(OUT,vertex), NoOpBarrierStep(2500)]
> {code}
> The only time this is cool is for {{RemoteTraversal}} because you want to 
> barrier as much as you can to reduce over the wire costs. However, 
> {{RemoteStrategy}} should append an end-barrier. No other strategy should do 
> this --- its just wasted clock cycles.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] tinkerpop pull request #559: TINKERPOP-1627: LazyBarrierStrategy should not ...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/559


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1627) LazyBarrierStrategy should not append an end barrier.

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/559
  
All tests pass with `docker/build.sh -t -n -i`

VOTE +1


> LazyBarrierStrategy should not append an end barrier.
> -
>
> Key: TINKERPOP-1627
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1627
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.5
>
>
> {code}
> gremlin> g.V().out().explain()
> ==>Traversal Explanation
> ==
> Original Traversal [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex)]
> ConnectiveStrategy   [D]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex)]
> RangeByIsCountStrategy   [O]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex)]
> RepeatUnrollStrategy [O]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex)]
> MatchPredicateStrategy   [O]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex)]
> PathRetractionStrategy   [O]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex)]
> IncidentToAdjacentStrategy   [O]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex)]
> FilterRankingStrategy[O]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex)]
> InlineFilterStrategy [O]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex)]
> AdjacentToIncidentStrategy   [O]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex)]
> LazyBarrierStrategy  [O]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex), NoOpBarrierStep(2500)]
> TinkerGraphCountStrategy [P]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex), NoOpBarrierStep(2500)]
> TinkerGraphStepStrategy  [P]   [TinkerGraphStep(vertex,[]), 
> VertexStep(OUT,vertex), NoOpBarrierStep(2500)]
> ProfileStrategy  [F]   [TinkerGraphStep(vertex,[]), 
> VertexStep(OUT,vertex), NoOpBarrierStep(2500)]
> StandardVerificationStrategy [V]   [TinkerGraphStep(vertex,[]), 
> VertexStep(OUT,vertex), NoOpBarrierStep(2500)]
> Final Traversal[TinkerGraphStep(vertex,[]), 
> VertexStep(OUT,vertex), NoOpBarrierStep(2500)]
> {code}
> The only time this is cool is for {{RemoteTraversal}} because you want to 
> barrier as much as you can to reduce over the wire costs. However, 
> {{RemoteStrategy}} should append an end-barrier. No other strategy should do 
> this --- its just wasted clock cycles.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] tinkerpop issue #559: TINKERPOP-1627: LazyBarrierStrategy should not append ...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/559
  
All tests pass with `docker/build.sh -t -n -i`

VOTE +1


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1627) LazyBarrierStrategy should not append an end barrier.

[ASF GitHub Bot (JIRA)]

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

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

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/559
  
`docker/build.sh -t -i` succeeded.

VOTE: +1


> LazyBarrierStrategy should not append an end barrier.
> -
>
> Key: TINKERPOP-1627
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1627
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.5
>
>
> {code}
> gremlin> g.V().out().explain()
> ==>Traversal Explanation
> ==
> Original Traversal [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex)]
> ConnectiveStrategy   [D]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex)]
> RangeByIsCountStrategy   [O]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex)]
> RepeatUnrollStrategy [O]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex)]
> MatchPredicateStrategy   [O]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex)]
> PathRetractionStrategy   [O]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex)]
> IncidentToAdjacentStrategy   [O]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex)]
> FilterRankingStrategy[O]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex)]
> InlineFilterStrategy [O]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex)]
> AdjacentToIncidentStrategy   [O]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex)]
> LazyBarrierStrategy  [O]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex), NoOpBarrierStep(2500)]
> TinkerGraphCountStrategy [P]   [GraphStep(vertex,[]), 
> VertexStep(OUT,vertex), NoOpBarrierStep(2500)]
> TinkerGraphStepStrategy  [P]   [TinkerGraphStep(vertex,[]), 
> VertexStep(OUT,vertex), NoOpBarrierStep(2500)]
> ProfileStrategy  [F]   [TinkerGraphStep(vertex,[]), 
> VertexStep(OUT,vertex), NoOpBarrierStep(2500)]
> StandardVerificationStrategy [V]   [TinkerGraphStep(vertex,[]), 
> VertexStep(OUT,vertex), NoOpBarrierStep(2500)]
> Final Traversal[TinkerGraphStep(vertex,[]), 
> VertexStep(OUT,vertex), NoOpBarrierStep(2500)]
> {code}
> The only time this is cool is for {{RemoteTraversal}} because you want to 
> barrier as much as you can to reduce over the wire costs. However, 
> {{RemoteStrategy}} should append an end-barrier. No other strategy should do 
> this --- its just wasted clock cycles.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] tinkerpop issue #559: TINKERPOP-1627: LazyBarrierStrategy should not append ...

[dkuppitz]

Github user dkuppitz commented on the issue:

https://github.com/apache/tinkerpop/pull/559
  
`docker/build.sh -t -i` succeeded.

VOTE: +1


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1631) Fix visibility issues with the BindingsGremlinPlugin

[ASF GitHub Bot (JIRA)]

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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/558
  
VOTE +1.



> Fix visibility issues with the BindingsGremlinPlugin
> 
>
> Key: TINKERPOP-1631
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1631
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: plugin
>Affects Versions: 3.2.3
>Reporter: stephen mallette
>Assignee: stephen mallette
> Fix For: 3.2.5
>
>
> The whole aspect of applying bindings via plugin with the revised plugin 
> system is a little sketchy/inconsistent. 
> * Bindings should always be assigned to global scope because engine scope is 
> always overriden with local bindings.
> * Bindings assigned by {{HadoopGremlinPlugin}} don't seem to want to appear 
> in Gremlin Server.
> * There needs to be some form of mock {{GremlinScriptEngine}} that can be 
> used to test plugins without having to depend on an actual implementation 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] tinkerpop issue #558: TINKERPOP-1631 Improvements to BindingsGremlinPlugin

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/558
  
VOTE +1.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TINKERPOP-1443) Use an API checker during build

[ASF GitHub Bot (JIRA)]

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

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

Github user metlos commented on the issue:

https://github.com/apache/tinkerpop/pull/494
  
So in another words it is a matter of setting up the level of breakage you 
want to allow between different Tinkerpop versions. I based the "minor increase 
allows breaking changes" on the "feeling" I got from how Tinkerpop changed over 
time, but you may want to modify it if you so choose.


> Use an API checker during build
> ---
>
> Key: TINKERPOP-1443
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1443
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: build-release
>Affects Versions: 3.2.2
>Reporter: Lukas Krejci
>Assignee: stephen mallette
>
> Tinkerpop 3.2.2 changed the signature of the method 
> {{GraphTraversal.hasLabel}} from {{(String...)}} to {{(String, String...)}}. 
> While this is certainly an improvement, it is both source and binary 
> incompatible change.
> I.e. even if every usage of {{hasLabel}} had at least one parameter in the 
> user code, none of those calls will work until all the user code is 
> recompiled using Tinkerpop 3.2.2.
> I don't know the versioning policy of Tinkerpop but changes like the above in 
> a micro/patch release are generally unexpected.
> Please consider API checkers like http://revapi.org to warn about such 
> incompatible API changes...



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] tinkerpop issue #494: TINKERPOP-1443 - Introduce API check into the build

[metlos]

Github user metlos commented on the issue:

https://github.com/apache/tinkerpop/pull/494
  
So in another words it is a matter of setting up the level of breakage you 
want to allow between different Tinkerpop versions. I based the "minor increase 
allows breaking changes" on the "feeling" I got from how Tinkerpop changed over 
time, but you may want to modify it if you so choose.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---