Re: [jira] [Commented] (TINKERPOP-1506) Optional/Coalesce should not allow sideEffect traversals.

[pieter-gmail]

Hi,

`coalesce` was discussed way back when `optional` was first discussed.
@Daniel's comment seems to show that `coalesce` was not what we wanted.
@Marko's comment indicated "Ah smart. The reason choose works and
coalesce doesn't is because one uses globalTraversals and the other uses
localTraversals"

Do there comments still hold?

Thanks
Pieter

On 21/10/2016 23:42, Marko A. Rodriguez (JIRA) wrote:
> [ 
> https://issues.apache.org/jira/browse/TINKERPOP-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15596463#comment-15596463
>  ] 
>
> Marko A. Rodriguez commented on TINKERPOP-1506:
> ---
>
> Huh. I just reailzed we can implement {{optional()}} using {{ColesceStep}} 
> and we don't have this problem.
>
> {code}
> gremlin> g.inject(1).coalesce(addV('twin'),identity())
> ==>v[0]
> gremlin> g.V()
> ==>v[0]
> {code}
>
> Thus, {{optional(x)}} -> {{coalesce(x,identity())}}. Easy fix. Any objections 
> to this direction?
>
>
>> Optional/Coalesce should not allow sideEffect traversals.
>> -
>>
>> Key: TINKERPOP-1506
>> URL: https://issues.apache.org/jira/browse/TINKERPOP-1506
>> Project: TinkerPop
>>  Issue Type: Improvement
>>  Components: process
>>Affects Versions: 3.1.4, 3.2.2
>>Reporter: Marko A. Rodriguez
>>
>> It took me a long time to realize what was wrong with a traversal I wrote 
>> that used {{optional(blah.sideEffect.blah)}}. {{optional()}} maps to 
>> {{ChooseStep}} under the hood and the provide traversal is first tested for 
>> a {{hasNext()}}. If so, the it plays itself out. The problem is that if 
>> there is a side-effect in the traversal child, then it gets executed twice. 
>> {code}
>> gremlin> g = TinkerGraph.open().traversal()
>> ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
>> gremlin> g.inject(1).optional(addV('twin'))
>> ==>v[1]
>> gremlin> g.V().valueMap(true)
>> ==>[id:0,label:twin]
>> ==>[id:1,label:twin]
>> {code}
>> We should NOT allow {{optional()}} to have {{SideEffectStep}} steps in it so 
>> as not to cause unexpected behavior. {{StandardVerificationStrategy}} can 
>> analyze and throw an exception if necessary.
>> Also, {{coalesce()}} has a similar problem, though perhaps it can be a 
>> useful 'technique.'
>> {code}
>> gremlin> g = TinkerGraph.open().traversal()
>> ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
>> gremlin> g.inject(1).coalesce(addV('twin1').limit(0), addV('twin2'))
>> ==>v[1]
>> gremlin> g.V().valueMap(true)
>> ==>[id:0,label:twin1]
>> ==>[id:1,label:twin2]
>> gremlin>
>> {code}
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1474) API Alignment Between Java Gremlin Graph Structure and GLVs

[Marko A. Rodriguez (JIRA)]

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

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

It is not suppose to have implementations as there is no Gremlin-Python VM. 
Gremlin-Python is only a language variant to generate Gremlin bytecode to send 
to Gremlin-Java VM.

> API Alignment Between Java Gremlin Graph Structure and GLVs
> ---
>
> Key: TINKERPOP-1474
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1474
> Project: TinkerPop
>  Issue Type: Bug
>  Components: io
>Affects Versions: 3.2.2
>Reporter: Adam Holmberg
>
> The current Java GraphSON implementation and that in the Python GLV leave 
> some question about what *should* be returned from a simple traversal like 
> `g.V()`.
> The java implementation presently assumes that properties could be present 
> and returns a DetachedVertex: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONSerializersV2d0.java#L420-L433
> The python implementation assumes no such thing and returns something more 
> reminiscent of a ReferenceVertex: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/structure/io/graphson.py#L238-L242
> Is the java version overreaching, and should not expect properties unless a 
> step calls for them (e.g. ` g.V().valueMap()` or `g.V().values('name')`, or 
> should the Python version be expanded?
> Is there something we can do to establish guidelines for this, and align 
> these APIs?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1507) Pick.any and Pick.none are not in GraphSON or Gremlin-Python

[ASF GitHub Bot (JIRA)]

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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/460
  
Its branched off the `tp32` line. I just fuggled the "wants to merge to." I 
will merge it to `tp32` come the time and upmerge to `master`.



> Pick.any and Pick.none are not in GraphSON or Gremlin-Python
> 
>
> Key: TINKERPOP-1507
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1507
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io, language-variant, process
>Affects Versions: 3.1.4, 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> There are numerous "tokens" (enums) in Gremlin -- {{T}}, {{Order}}, 
> {{Compare}}, etc.
> We forgot {{Pick}}. Doh. {{Pick}} is used in branch-options to support 
> "default" and "all"-type semantics in switch behavior. We need to add it to 
> GraphSON and Gremlin-Python.
> More generally, I think we should consolidate all the "tokens" into a single 
> Java file.
> {code}
> public class Tokens {
>   public enum T { .. }
>   public enum Order { .. }
>   public enum VertexCardinality { ..}
>   public enum Compare { .. }
>   public enum Pick { .. } 
>   ...
> }
> {code}
> We could make it backwards compatible by:
> {code}
> T.label = Tokens.T.label.
> {code}
> By having all this consolidate, we will more easily know what we have and 
> will be better able to use reflection in language variant generators.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1474) API Alignment Between Java Gremlin Graph Structure and GLVs

[Andy Tolbert (JIRA)]

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

Andy Tolbert commented on TINKERPOP-1474:
-

I also noticed that in {{gremlin-python}} that {{VertexProperty}} also doesn't 
have {{properties}} itself, so if you have a property with meta-properties they 
will not be accessible with GLV.  I assume this is a similar line of reasoning 
to {{Vertex}} and {{Edge}} not having properties, but I thought I would point 
that out as well.

> API Alignment Between Java Gremlin Graph Structure and GLVs
> ---
>
> Key: TINKERPOP-1474
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1474
> Project: TinkerPop
>  Issue Type: Bug
>  Components: io
>Affects Versions: 3.2.2
>Reporter: Adam Holmberg
>
> The current Java GraphSON implementation and that in the Python GLV leave 
> some question about what *should* be returned from a simple traversal like 
> `g.V()`.
> The java implementation presently assumes that properties could be present 
> and returns a DetachedVertex: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONSerializersV2d0.java#L420-L433
> The python implementation assumes no such thing and returns something more 
> reminiscent of a ReferenceVertex: 
> https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/structure/io/graphson.py#L238-L242
> Is the java version overreaching, and should not expect properties unless a 
> step calls for them (e.g. ` g.V().valueMap()` or `g.V().values('name')`, or 
> should the Python version be expanded?
> Is there something we can do to establish guidelines for this, and align 
> these APIs?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1507) Pick.any and Pick.none are not in GraphSON or Gremlin-Python

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/460
  
Shouldn't this be a fix to tp32 and 3.2.x line?


> Pick.any and Pick.none are not in GraphSON or Gremlin-Python
> 
>
> Key: TINKERPOP-1507
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1507
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io, language-variant, process
>Affects Versions: 3.1.4, 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> There are numerous "tokens" (enums) in Gremlin -- {{T}}, {{Order}}, 
> {{Compare}}, etc.
> We forgot {{Pick}}. Doh. {{Pick}} is used in branch-options to support 
> "default" and "all"-type semantics in switch behavior. We need to add it to 
> GraphSON and Gremlin-Python.
> More generally, I think we should consolidate all the "tokens" into a single 
> Java file.
> {code}
> public class Tokens {
>   public enum T { .. }
>   public enum Order { .. }
>   public enum VertexCardinality { ..}
>   public enum Compare { .. }
>   public enum Pick { .. } 
>   ...
> }
> {code}
> We could make it backwards compatible by:
> {code}
> T.label = Tokens.T.label.
> {code}
> By having all this consolidate, we will more easily know what we have and 
> will be better able to use reflection in language variant generators.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop issue #460: TINKERPOP-1507: Pick.any and Pick.none are not in Grap...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/460
  
Shouldn't this be a fix to tp32 and 3.2.x line?


---
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] [Created] (TINKERPOP-1524) Bytecode.getXXXInstructions should return a List, not Iterable.

[Marko A. Rodriguez (JIRA)]

Marko A. Rodriguez created TINKERPOP-1524:
-

 Summary: Bytecode.getXXXInstructions should return a List, not 
Iterable.
 Key: TINKERPOP-1524
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1524
 Project: TinkerPop
  Issue Type: Improvement
  Components: language-variant, process
Affects Versions: 3.2.3
Reporter: Marko A. Rodriguez


Its pointless to return an iterable. Its not like its going to be that much 
data that we will ever need to stream it. Moreover, then we can do stuff like 
{{get(1)}} and {{size()}} more easily.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1506) Optional/Coalesce should not allow sideEffect traversals.

[Marko A. Rodriguez (JIRA)]

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

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

Huh. I just reailzed we can implement {{optional()}} using {{ColesceStep}} and 
we don't have this problem.

{code}
gremlin> g.inject(1).coalesce(addV('twin'),identity())
==>v[0]
gremlin> g.V()
==>v[0]
{code}

Thus, {{optional(x)}} -> {{coalesce(x,identity())}}. Easy fix. Any objections 
to this direction?


> Optional/Coalesce should not allow sideEffect traversals.
> -
>
> Key: TINKERPOP-1506
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1506
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.1.4, 3.2.2
>Reporter: Marko A. Rodriguez
>
> It took me a long time to realize what was wrong with a traversal I wrote 
> that used {{optional(blah.sideEffect.blah)}}. {{optional()}} maps to 
> {{ChooseStep}} under the hood and the provide traversal is first tested for a 
> {{hasNext()}}. If so, the it plays itself out. The problem is that if there 
> is a side-effect in the traversal child, then it gets executed twice. 
> {code}
> gremlin> g = TinkerGraph.open().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
> gremlin> g.inject(1).optional(addV('twin'))
> ==>v[1]
> gremlin> g.V().valueMap(true)
> ==>[id:0,label:twin]
> ==>[id:1,label:twin]
> {code}
> We should NOT allow {{optional()}} to have {{SideEffectStep}} steps in it so 
> as not to cause unexpected behavior. {{StandardVerificationStrategy}} can 
> analyze and throw an exception if necessary.
> Also, {{coalesce()}} has a similar problem, though perhaps it can be a useful 
> 'technique.'
> {code}
> gremlin> g = TinkerGraph.open().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
> gremlin> g.inject(1).coalesce(addV('twin1').limit(0), addV('twin2'))
> ==>v[1]
> gremlin> g.V().valueMap(true)
> ==>[id:0,label:twin1]
> ==>[id:1,label:twin2]
> gremlin>
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1468) GraphTraversal.optional throws a NPE if no traversal is provided

[Marko A. Rodriguez (JIRA)]

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

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

This is really weird because there is no method signature that allows for no 
args.

{code}
public default  GraphTraversal optional(final Traversal 
optionalTraversal) {
this.asAdmin().getBytecode().addStep(Symbols.optional, 
optionalTraversal);
return this.asAdmin().addStep(new ChooseStep<>(this.asAdmin(), 
(Traversal.Admin) optionalTraversal, (Traversal.Admin) 
optionalTraversal.asAdmin().clone(), (Traversal.Admin) 
__.identity()));
}

{code}

And its dying on the {{clone()}} call. I don't know why Groovy isn't throwing a 
"no such method found exception".

> GraphTraversal.optional throws a NPE if no traversal is provided
> 
>
> Key: TINKERPOP-1468
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1468
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Ted Wilmes
>  Labels: trivial
>
> {{GraphTraversal.optional}} throws a NPE if no traversal is provided.  We 
> should probably throw a friendlier exception with instructions to provide a 
> traversal as an argument.
> {code}
> gremlin> g.V().optional()
> java.lang.NullPointerException
> Type ':help' or ':h' for help.
> Display stack trace? [yN]y
> java.lang.NullPointerException
>   at 
> org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal.optional(GraphTraversal.java:1316)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1507) Pick.any and Pick.none are not in GraphSON or Gremlin-Python

[ASF GitHub Bot (JIRA)]

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

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

GitHub user okram opened a pull request:

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

TINKERPOP-1507: Pick.any and Pick.none are not in GraphSON or Gremlin-Python

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

`Pick.any` and `Pick.none` were not in any of the registered serialization 
systems -- Java or Python. Nor in the static imports. This has since been 
rectified and two new test cases add to `BranchTest` and `ChooseTest` to 
demonstrate that these tokens are now being processed correctly.

CHANGELOG

```
* Added `Pick.none` and `Pick.any` to the serializers and importers.
```

VOTE +1.

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

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

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

https://github.com/apache/tinkerpop/pull/460.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 #460


commit 0fec46db21a3af0604a85b9b4bed4e47db8d1a70
Author: Marko A. Rodriguez 
Date:   2016-10-21T19:07:18Z

added Pick.none and Pick.any to the CoreImports. Added it to both 
GraphSONModule and GryoMapper. Added two new test cases which use any and none 
-- one in ChooseTest and one in BranchTest. Added none/any to GroovyTranslator 
and PythonTranslator. All good in the hood.




> Pick.any and Pick.none are not in GraphSON or Gremlin-Python
> 
>
> Key: TINKERPOP-1507
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1507
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io, language-variant, process
>Affects Versions: 3.1.4, 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> There are numerous "tokens" (enums) in Gremlin -- {{T}}, {{Order}}, 
> {{Compare}}, etc.
> We forgot {{Pick}}. Doh. {{Pick}} is used in branch-options to support 
> "default" and "all"-type semantics in switch behavior. We need to add it to 
> GraphSON and Gremlin-Python.
> More generally, I think we should consolidate all the "tokens" into a single 
> Java file.
> {code}
> public class Tokens {
>   public enum T { .. }
>   public enum Order { .. }
>   public enum VertexCardinality { ..}
>   public enum Compare { .. }
>   public enum Pick { .. } 
>   ...
> }
> {code}
> We could make it backwards compatible by:
> {code}
> T.label = Tokens.T.label.
> {code}
> By having all this consolidate, we will more easily know what we have and 
> will be better able to use reflection in language variant generators.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TINKERPOP-1507) Pick.any and Pick.none are not in GraphSON or Gremlin-Python

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez reassigned TINKERPOP-1507:
-

Assignee: Marko A. Rodriguez

> Pick.any and Pick.none are not in GraphSON or Gremlin-Python
> 
>
> Key: TINKERPOP-1507
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1507
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io, language-variant, process
>Affects Versions: 3.1.4, 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> There are numerous "tokens" (enums) in Gremlin -- {{T}}, {{Order}}, 
> {{Compare}}, etc.
> We forgot {{Pick}}. Doh. {{Pick}} is used in branch-options to support 
> "default" and "all"-type semantics in switch behavior. We need to add it to 
> GraphSON and Gremlin-Python.
> More generally, I think we should consolidate all the "tokens" into a single 
> Java file.
> {code}
> public class Tokens {
>   public enum T { .. }
>   public enum Order { .. }
>   public enum VertexCardinality { ..}
>   public enum Compare { .. }
>   public enum Pick { .. } 
>   ...
> }
> {code}
> We could make it backwards compatible by:
> {code}
> T.label = Tokens.T.label.
> {code}
> By having all this consolidate, we will more easily know what we have and 
> will be better able to use reflection in language variant generators.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1507) Pick.any and Pick.none are not in GraphSON or Gremlin-Python

[Marko A. Rodriguez (JIRA)]

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

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

Went down the road of a {{Tokens.java}} file and its not good. Its only useful 
for JVM languages --- Python and others will have to do lots of conversions. 
Just going to stay the course and added {{Pick}} to the enum imports.

> Pick.any and Pick.none are not in GraphSON or Gremlin-Python
> 
>
> Key: TINKERPOP-1507
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1507
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io, language-variant, process
>Affects Versions: 3.1.4, 3.2.2
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> There are numerous "tokens" (enums) in Gremlin -- {{T}}, {{Order}}, 
> {{Compare}}, etc.
> We forgot {{Pick}}. Doh. {{Pick}} is used in branch-options to support 
> "default" and "all"-type semantics in switch behavior. We need to add it to 
> GraphSON and Gremlin-Python.
> More generally, I think we should consolidate all the "tokens" into a single 
> Java file.
> {code}
> public class Tokens {
>   public enum T { .. }
>   public enum Order { .. }
>   public enum VertexCardinality { ..}
>   public enum Compare { .. }
>   public enum Pick { .. } 
>   ...
> }
> {code}
> We could make it backwards compatible by:
> {code}
> T.label = Tokens.T.label.
> {code}
> By having all this consolidate, we will more easily know what we have and 
> will be better able to use reflection in language variant generators.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (TINKERPOP-1498) choose() can throw StackOverflowErrors

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz closed TINKERPOP-1498.
-
Resolution: Won't Fix

Okay, no problem, it was indeed a bad query.

> choose() can throw StackOverflowErrors
> --
>
> Key: TINKERPOP-1498
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1498
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.2
>Reporter: Daniel Kuppitz
>
> {noformat}
> gremlin> g = TinkerFactory.createModern().traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V().choose(select("x"), select("x"), constant("not x")).store("x")
> java.lang.StackOverflowError
> Type ':help' or ':h' for help.
> Display stack trace? [yN]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (TINKERPOP-1484) Bad interaction of long-typed vertex properties with TinkerGraph indexes

[Florin Mihaila (JIRA)]

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

Florin Mihaila edited comment on TINKERPOP-1484 at 10/21/16 4:37 PM:
-

I only now see that you had actually mentioned that this affects ids in an 
earlier comment. I only hit the issue today and I'd forgotten about that 
comment.


was (Author: f...@objectline.com):
I only now see that you had actually mentioned that this affects ids in your 
comment above. I only hit the issue today and I'd forgotten about that comment.

> Bad interaction of long-typed vertex properties with TinkerGraph indexes
> 
>
> Key: TINKERPOP-1484
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1484
> Project: TinkerPop
>  Issue Type: Bug
>  Components: tinkergraph
>Affects Versions: 3.2.2, 3.2.3
> Environment: macOS Sierra (v10.12), jdk 1.8.0_102-b14 
>Reporter: Florin Mihaila
>Priority: Minor
>
> In graphs with indexed properties, queries fail on certain vertices (but 
> not all) with properties of type long.
> 
> The following code reproduces the bug:
> 
> {code:title=bug.groovy}
> graph = TinkerGraph.open() 
> graph.createIndex('other', Vertex.class) // (A)
> graph.createIndex('prop', Vertex.class)  // (B)
>   
> v = graph.addVertex()
> v.property('prop', (long)1)
> v.property('other', 0)
>   
> v = graph.addVertex()
> v.property('prop', 12345678910)
> v.property('other', 1)
>   
> g = graph.traversal()
> {code}
> 
> The verbatim console session:
>   
> {noformat}
> $ bin/gremlin.sh bug.groovy
>   
>  \,,,/
>  (o o)
> -oOOo-(3)-oOOo-
> plugin activated: tinkerpop.server
> plugin activated: tinkerpop.utilities
> plugin activated: tinkerpop.tinkergraph
> gremlin> g.V().valueMap()
> ==>[other:[0],prop:[1]]
> ==>[other:[1],prop:[12345678910]]
> gremlin> g.V().has('prop', 1)   // (1)
> gremlin> g.V().has('prop', (long)1)   // (2) 
> ==>v[0]
> gremlin> g.V().has('other', 0).has('prop', 1) // (3)
> ==>v[0]
> gremlin> g.V().has('prop', 12345678910) // (4)
> ==>v[3]
> gremlin> 
>   
> {noformat}  
>   
> h4. Observations:
> 1. The node is _not_ found, although it's there.
> 2. The node _is_ found if the property value is explicitly cast to long.
> 3. The node _is_ found if the graph is queried on another indexed 
> property first.
> 4. The node _is_ found if the property value is wider than an int.
> 
> h4. Variations:
> v1. If the 'other' property is not indexed (line A), query (2) fails.
> v2. If the 'prop' property is not indexed (line B), all queries succeed!
>   
> Tested on freshly built tinkerpop distributions, versions 3.2.2 and 3.2.3.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1484) Bad interaction of long-typed vertex properties with TinkerGraph indexes

[Florin Mihaila (JIRA)]

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

Florin Mihaila commented on TINKERPOP-1484:
---

I only now see that you had actually mentioned that this affects ids in your 
comment above. I only hit the issue today and I'd forgotten about that comment.

> Bad interaction of long-typed vertex properties with TinkerGraph indexes
> 
>
> Key: TINKERPOP-1484
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1484
> Project: TinkerPop
>  Issue Type: Bug
>  Components: tinkergraph
>Affects Versions: 3.2.2, 3.2.3
> Environment: macOS Sierra (v10.12), jdk 1.8.0_102-b14 
>Reporter: Florin Mihaila
>Priority: Minor
>
> In graphs with indexed properties, queries fail on certain vertices (but 
> not all) with properties of type long.
> 
> The following code reproduces the bug:
> 
> {code:title=bug.groovy}
> graph = TinkerGraph.open() 
> graph.createIndex('other', Vertex.class) // (A)
> graph.createIndex('prop', Vertex.class)  // (B)
>   
> v = graph.addVertex()
> v.property('prop', (long)1)
> v.property('other', 0)
>   
> v = graph.addVertex()
> v.property('prop', 12345678910)
> v.property('other', 1)
>   
> g = graph.traversal()
> {code}
> 
> The verbatim console session:
>   
> {noformat}
> $ bin/gremlin.sh bug.groovy
>   
>  \,,,/
>  (o o)
> -oOOo-(3)-oOOo-
> plugin activated: tinkerpop.server
> plugin activated: tinkerpop.utilities
> plugin activated: tinkerpop.tinkergraph
> gremlin> g.V().valueMap()
> ==>[other:[0],prop:[1]]
> ==>[other:[1],prop:[12345678910]]
> gremlin> g.V().has('prop', 1)   // (1)
> gremlin> g.V().has('prop', (long)1)   // (2) 
> ==>v[0]
> gremlin> g.V().has('other', 0).has('prop', 1) // (3)
> ==>v[0]
> gremlin> g.V().has('prop', 12345678910) // (4)
> ==>v[3]
> gremlin> 
>   
> {noformat}  
>   
> h4. Observations:
> 1. The node is _not_ found, although it's there.
> 2. The node _is_ found if the property value is explicitly cast to long.
> 3. The node _is_ found if the graph is queried on another indexed 
> property first.
> 4. The node _is_ found if the property value is wider than an int.
> 
> h4. Variations:
> v1. If the 'other' property is not indexed (line A), query (2) fails.
> v2. If the 'prop' property is not indexed (line B), all queries succeed!
>   
> Tested on freshly built tinkerpop distributions, versions 3.2.2 and 3.2.3.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (TINKERPOP-1484) Bad interaction of long-typed vertex properties with TinkerGraph indexes

[Florin Mihaila (JIRA)]

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

Florin Mihaila edited comment on TINKERPOP-1484 at 10/21/16 4:31 PM:
-

This also affects querying the graph by vertex id. The automatically created id 
index seems to use longs, leading to vertices queried by id not to be found, 
unless the key is explicitly marked as long.

In continuation of the previous session:

{noformat}
gremlin> g.V().valueMap(true)
==>[other:[0],prop:[1],id:0,label:vertex]
==>[other:[1],prop:[12345678910],id:3,label:vertex]
gremlin> g.V().hasId(0)
gremlin> g.V().hasId(0L)
==>v[0]
{noformat}

This behaviour is expected based on the above discussion, but it doesn't 
involve an explicitly created index, so I am mentioning this for the benefit of 
others who may be tripped up by it.



was (Author: f...@objectline.com):
This also affects querying the graph by vertex id. The automatically created id 
index seems to use longs, leading to vertices queried by id not to be found, 
unless the key is explicitly marked as long.

In continuation of the previous session:

{noformat}
gremlin> g.V().valueMap(true)
==>[other:[0],prop:[1],id:0,label:vertex]
==>[other:[1],prop:[12345678910],id:3,label:vertex]
gremlin> g.V().hasId(0)
gremlin> g.V().hasId(0L)
==>v[0]
{noformat}

This behaviour is expected based on the above discussion, but it doesn't 
involve an explicitly created index, so I am mentioning this for the benefit of 
others who may be tripped up by this behaviour.


> Bad interaction of long-typed vertex properties with TinkerGraph indexes
> 
>
> Key: TINKERPOP-1484
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1484
> Project: TinkerPop
>  Issue Type: Bug
>  Components: tinkergraph
>Affects Versions: 3.2.2, 3.2.3
> Environment: macOS Sierra (v10.12), jdk 1.8.0_102-b14 
>Reporter: Florin Mihaila
>Priority: Minor
>
> In graphs with indexed properties, queries fail on certain vertices (but 
> not all) with properties of type long.
> 
> The following code reproduces the bug:
> 
> {code:title=bug.groovy}
> graph = TinkerGraph.open() 
> graph.createIndex('other', Vertex.class) // (A)
> graph.createIndex('prop', Vertex.class)  // (B)
>   
> v = graph.addVertex()
> v.property('prop', (long)1)
> v.property('other', 0)
>   
> v = graph.addVertex()
> v.property('prop', 12345678910)
> v.property('other', 1)
>   
> g = graph.traversal()
> {code}
> 
> The verbatim console session:
>   
> {noformat}
> $ bin/gremlin.sh bug.groovy
>   
>  \,,,/
>  (o o)
> -oOOo-(3)-oOOo-
> plugin activated: tinkerpop.server
> plugin activated: tinkerpop.utilities
> plugin activated: tinkerpop.tinkergraph
> gremlin> g.V().valueMap()
> ==>[other:[0],prop:[1]]
> ==>[other:[1],prop:[12345678910]]
> gremlin> g.V().has('prop', 1)   // (1)
> gremlin> g.V().has('prop', (long)1)   // (2) 
> ==>v[0]
> gremlin> g.V().has('other', 0).has('prop', 1) // (3)
> ==>v[0]
> gremlin> g.V().has('prop', 12345678910) // (4)
> ==>v[3]
> gremlin> 
>   
> {noformat}  
>   
> h4. Observations:
> 1. The node is _not_ found, although it's there.
> 2. The node _is_ found if the property value is explicitly cast to long.
> 3. The node _is_ found if the graph is queried on another indexed 
> property first.
> 4. The node _is_ found if the property value is wider than an int.
> 
> h4. Variations:
> v1. If the 'other' property is not indexed (line A), query (2) fails.
> v2. If the 'prop' property is not indexed (line B), all queries succeed!
>   
> Tested on freshly built tinkerpop distributions, versions 3.2.2 and 3.2.3.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (TINKERPOP-1484) Bad interaction of long-typed vertex properties with TinkerGraph indexes

[Florin Mihaila (JIRA)]

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

Florin Mihaila edited comment on TINKERPOP-1484 at 10/21/16 4:29 PM:
-

This also affects querying the graph by vertex id. The automatically created id 
index seems to use longs, leading to vertices queried by id not to be found, 
unless the key is explicitly marked as long.

In continuation of the previous session:

{noformat}
gremlin> g.V().valueMap(true)
==>[other:[0],prop:[1],id:0,label:vertex]
==>[other:[1],prop:[12345678910],id:3,label:vertex]
gremlin> g.V().hasId(0)
gremlin> g.V().hasId(0L)
==>v[0]
{noformat}

This behaviour is expected based on the above discussion, but it doesn't 
involve an explicitly created index, so I am mentioning this for the benefit of 
others who may be tripped up by this behaviour.



was (Author: f...@objectline.com):
This also affects querying the graph by vertex id. The automatically created id 
index seems to use longs, leading to vertices queried by id not to be found, 
unless the key is explicitly marked as long.

In continuation of the previous session:

{noformat}
gremlin> g.V().valueMap(true)
==>[other:[0],prop:[1],id:0,label:vertex]
==>[other:[1],prop:[12345678910],id:3,label:vertex]
gremlin> g.V().hasId(0)
gremlin> g.V().hasId(0L)
==>v[0]
{noformat}

This behaviour is expected based on the above discussion, but I am mentioning 
this for the benefit of others who may be tripped up by this behaviour.


> Bad interaction of long-typed vertex properties with TinkerGraph indexes
> 
>
> Key: TINKERPOP-1484
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1484
> Project: TinkerPop
>  Issue Type: Bug
>  Components: tinkergraph
>Affects Versions: 3.2.2, 3.2.3
> Environment: macOS Sierra (v10.12), jdk 1.8.0_102-b14 
>Reporter: Florin Mihaila
>Priority: Minor
>
> In graphs with indexed properties, queries fail on certain vertices (but 
> not all) with properties of type long.
> 
> The following code reproduces the bug:
> 
> {code:title=bug.groovy}
> graph = TinkerGraph.open() 
> graph.createIndex('other', Vertex.class) // (A)
> graph.createIndex('prop', Vertex.class)  // (B)
>   
> v = graph.addVertex()
> v.property('prop', (long)1)
> v.property('other', 0)
>   
> v = graph.addVertex()
> v.property('prop', 12345678910)
> v.property('other', 1)
>   
> g = graph.traversal()
> {code}
> 
> The verbatim console session:
>   
> {noformat}
> $ bin/gremlin.sh bug.groovy
>   
>  \,,,/
>  (o o)
> -oOOo-(3)-oOOo-
> plugin activated: tinkerpop.server
> plugin activated: tinkerpop.utilities
> plugin activated: tinkerpop.tinkergraph
> gremlin> g.V().valueMap()
> ==>[other:[0],prop:[1]]
> ==>[other:[1],prop:[12345678910]]
> gremlin> g.V().has('prop', 1)   // (1)
> gremlin> g.V().has('prop', (long)1)   // (2) 
> ==>v[0]
> gremlin> g.V().has('other', 0).has('prop', 1) // (3)
> ==>v[0]
> gremlin> g.V().has('prop', 12345678910) // (4)
> ==>v[3]
> gremlin> 
>   
> {noformat}  
>   
> h4. Observations:
> 1. The node is _not_ found, although it's there.
> 2. The node _is_ found if the property value is explicitly cast to long.
> 3. The node _is_ found if the graph is queried on another indexed 
> property first.
> 4. The node _is_ found if the property value is wider than an int.
> 
> h4. Variations:
> v1. If the 'other' property is not indexed (line A), query (2) fails.
> v2. If the 'prop' property is not indexed (line B), all queries succeed!
>   
> Tested on freshly built tinkerpop distributions, versions 3.2.2 and 3.2.3.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1484) Bad interaction of long-typed vertex properties with TinkerGraph indexes

[Florin Mihaila (JIRA)]

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

Florin Mihaila commented on TINKERPOP-1484:
---

This also affects querying the graph by vertex id. The automatically created id 
index seems to use longs, leading to vertices queried by id not to be found, 
unless the key is explicitly marked as long.

In continuation of the previous session:

{noformat}
gremlin> g.V().valueMap(true)
==>[other:[0],prop:[1],id:0,label:vertex]
==>[other:[1],prop:[12345678910],id:3,label:vertex]
gremlin> g.V().hasId(0)
gremlin> g.V().hasId(0L)
==>v[0]
{noformat}

This behaviour is expected based on the above discussion, but I am mentioning 
this for the benefit of others who may be tripped up by this behaviour.


> Bad interaction of long-typed vertex properties with TinkerGraph indexes
> 
>
> Key: TINKERPOP-1484
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1484
> Project: TinkerPop
>  Issue Type: Bug
>  Components: tinkergraph
>Affects Versions: 3.2.2, 3.2.3
> Environment: macOS Sierra (v10.12), jdk 1.8.0_102-b14 
>Reporter: Florin Mihaila
>Priority: Minor
>
> In graphs with indexed properties, queries fail on certain vertices (but 
> not all) with properties of type long.
> 
> The following code reproduces the bug:
> 
> {code:title=bug.groovy}
> graph = TinkerGraph.open() 
> graph.createIndex('other', Vertex.class) // (A)
> graph.createIndex('prop', Vertex.class)  // (B)
>   
> v = graph.addVertex()
> v.property('prop', (long)1)
> v.property('other', 0)
>   
> v = graph.addVertex()
> v.property('prop', 12345678910)
> v.property('other', 1)
>   
> g = graph.traversal()
> {code}
> 
> The verbatim console session:
>   
> {noformat}
> $ bin/gremlin.sh bug.groovy
>   
>  \,,,/
>  (o o)
> -oOOo-(3)-oOOo-
> plugin activated: tinkerpop.server
> plugin activated: tinkerpop.utilities
> plugin activated: tinkerpop.tinkergraph
> gremlin> g.V().valueMap()
> ==>[other:[0],prop:[1]]
> ==>[other:[1],prop:[12345678910]]
> gremlin> g.V().has('prop', 1)   // (1)
> gremlin> g.V().has('prop', (long)1)   // (2) 
> ==>v[0]
> gremlin> g.V().has('other', 0).has('prop', 1) // (3)
> ==>v[0]
> gremlin> g.V().has('prop', 12345678910) // (4)
> ==>v[3]
> gremlin> 
>   
> {noformat}  
>   
> h4. Observations:
> 1. The node is _not_ found, although it's there.
> 2. The node _is_ found if the property value is explicitly cast to long.
> 3. The node _is_ found if the graph is queried on another indexed 
> property first.
> 4. The node _is_ found if the property value is wider than an int.
> 
> h4. Variations:
> v1. If the 'other' property is not indexed (line A), query (2) fails.
> v2. If the 'prop' property is not indexed (line B), all queries succeed!
>   
> Tested on freshly built tinkerpop distributions, versions 3.2.2 and 3.2.3.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[BLOG] A Gremlin Implementation of the Gremlin Traversal Machine

[Marko Rodriguez]

Hello,

This post is a doozy. However, if you understand it, you understand some of the 
most fundamental concepts of computing and I think (and argue), the nature of 
reality itself.

https://twitter.com/twarko/status/789479876856164352 


Enjoy,
Marko. 

http://markorodriguez.com

[jira] [Commented] (TINKERPOP-1485) Move source for TinkerPop site to source code repo

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/459
  
I have used this several times now in relation to 3.1.5/3.2.3 release and 
it works nicely:

VOTE +1

hopefully it works as nicely for @okram :)


> Move source for TinkerPop site to source code repo
> --
>
> Key: TINKERPOP-1485
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1485
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.2.2
>Reporter: stephen mallette
>Assignee: Daniel Kuppitz
> Fix For: 3.3.0
>
>
> Some time ago there was discussion on the Mailing List to move the web site 
> to the source code repo so that it could be contributed to via pull request. 
> It would be nice because then we could better rely on some basic static site 
> generation to help deal with repetitive and sometimes error prone process of 
> updating the header for the pages.
> Anyway, a few thoughts:
> 1. need a shell script to publish the site to svn - something like 
> {{bin/publish-site.sh}}
> 2. place files in the root of the project in a directory called {{site/}}
> 3. if possible, do some basic site generation with maybe some groovy script 
> or just the shell script mentioned above to inject a "header file" for each 
> page.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop issue #459: TINKERPOP-1485 Move source for TinkerPop site to sourc...

[spmallette]

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/459
  
I have used this several times now in relation to 3.1.5/3.2.3 release and 
it works nicely:

VOTE +1

hopefully it works as nicely for @okram :)


---
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.
---

TinkerPop 3.1.5 Released: A 187 On The Undercover Gremlinz

[Ted Wilmes]

Hello,

TinkerPop 3.1.5 has just been released.  This maintenance release contains
a number of bug fixes on the "Undercover Gremlinz" release line and should
be non-breaking for your upgrade needs.

The release artifacts can be found at this location:

https://www.apache.org/dyn/closer.lua/tinkerpop/3.1.5/
apache-tinkerpop-gremlin-console-3.1.5-bin.zip
https://www.apache.org/dyn/closer.lua/tinkerpop/3.1.5/
apache-tinkerpop-gremlin-server-3.1.5-bin.zip

The online docs can be found here:

http://tinkerpop.apache.org/docs/3.1.5/reference/ (user docs)
http://tinkerpop.apache.org/docs/3.1.5/upgrade/ (upgrade docs)
http://tinkerpop.apache.org/javadocs/3.1.5/core/ (core javadoc)
http://tinkerpop.apache.org/javadocs/3.1.5/full/ (full javadoc)

The release notes are available here:

https://github.com/apache/tinkerpop/blob/3.1.5/CHANGELOG.asciidoc

The Central Maven repo has sync’d as well:

https://repo1.maven.org/maven2/org/apache/tinkerpop/tinkerpop/3.1.5/

Enjoy!


​

[jira] [Commented] (TINKERPOP-1485) Move source for TinkerPop site to source code repo

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/459
  
forget that last post - that was dumb...i didn't merge your 
latest changes (i thought i'd done it last night)


> Move source for TinkerPop site to source code repo
> --
>
> Key: TINKERPOP-1485
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1485
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.2.2
>Reporter: stephen mallette
>Assignee: Daniel Kuppitz
> Fix For: 3.3.0
>
>
> Some time ago there was discussion on the Mailing List to move the web site 
> to the source code repo so that it could be contributed to via pull request. 
> It would be nice because then we could better rely on some basic static site 
> generation to help deal with repetitive and sometimes error prone process of 
> updating the header for the pages.
> Anyway, a few thoughts:
> 1. need a shell script to publish the site to svn - something like 
> {{bin/publish-site.sh}}
> 2. place files in the root of the project in a directory called {{site/}}
> 3. if possible, do some basic site generation with maybe some groovy script 
> or just the shell script mentioned above to inject a "header file" for each 
> page.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1485) Move source for TinkerPop site to source code repo

[ASF GitHub Bot (JIRA)]

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

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

Github user spmallette commented on the issue:

https://github.com/apache/tinkerpop/pull/459
  
I tried to use this to update the site for 3.2.3/3.1.5 and it didn't seem 
to work.  It didn't error, but nothing seemed to go to svn. Also, I see you 
create a `site/target` directory. I was using the root `/target` for stuff in 
my scripts. Is there any reason not to make that consistent? i'm fine with your 
directory local to `site/` btw - that's fine as long as it's all in one place.


> Move source for TinkerPop site to source code repo
> --
>
> Key: TINKERPOP-1485
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1485
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.2.2
>Reporter: stephen mallette
>Assignee: Daniel Kuppitz
> Fix For: 3.3.0
>
>
> Some time ago there was discussion on the Mailing List to move the web site 
> to the source code repo so that it could be contributed to via pull request. 
> It would be nice because then we could better rely on some basic static site 
> generation to help deal with repetitive and sometimes error prone process of 
> updating the header for the pages.
> Anyway, a few thoughts:
> 1. need a shell script to publish the site to svn - something like 
> {{bin/publish-site.sh}}
> 2. place files in the root of the project in a directory called {{site/}}
> 3. if possible, do some basic site generation with maybe some groovy script 
> or just the shell script mentioned above to inject a "header file" for each 
> page.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)