I see you have a SNAPSHOT in your README which i further see is published in sonatype, but we're looking for a release that is "stable". By "stable" I just mean that the code won't change out from under a user who depends on it (the way SNAPSHOTs do) and typically that release would tie to a tag in your source control system. So if you feel like you aren't quite ready for a "production" release of 1.0.0, you could publish a 1.0.0-beta1 or something like that. A "beta" or "RC" or whatever early release naming you want to use are all acceptable forms of "stable" for purpose of listing. A SNAPSHOT alone isn't quite enough.
On Wed, Aug 16, 2017 at 4:58 PM, Karthick Sankarachary <[email protected]> wrote: > Hi, Stephen, > > Before I send out an email to the broader dev mailing list, can you take a > look > to see if the following project complies with TinkerPop's listing policy? > > https://github.com/karthicks/gremlin-ogm > > Currently, it has one release based on TinkerPop 3.2.5. > > Also, I created the following issue to investigate whether the library > will work > with remote traversals: https://github.com/karthicks/gremlin-ogm/issues/1. > > Regards, > Karthick > > On 2017-08-15 11:25, "Karthick Sankarachary"<[email protected]> wrote: > > Hi, Stephen, > > > > Once I make sure the project satisfies the listing policy, I will email > it to the > > dev list for your approval. > > > > Thanks again! > > Karthick Sankarachary > > > > On 2017-08-15 10:29, Stephen Mallette <[email protected]> wrote: > > > Hi Karthick - thanks for joining the thread and thank you for > understanding > > > the position I took. Let me try to respond to your questions: > > > > > > 1) While it does introduce new object-centric Graph and Query > interfaces, > > > > > > > the goal there was to simply facilitate the object-gremlin mapping. The > > > > traversals are specified as lambdas, such as `g -> g.V().count()` or > > > > `traversal -> traversal.count()`, etc. As far as the provider > interface, I > > > > think I might be able to get rid of it, on second thoughts. All I > really > > > > need > > > > is a GraphTraversalSource. I may have to get rid of the ability to > execute > > > > scripts (traversals inside strings), but that'd be a small price to > pay. > > > > > > > > > > I think that "scripts' will one day (no time soon) be a dead notion in > > > TinkerPop. We actively try to discourage the pattern now that we > understand > > > how Gremlin bytecode and GLVs work, but I'm sure there is a lot of > > > production code out there that relies on "scripts". For the purpose of > your > > > project i'd agree that losing scripts is a small price to pay and in > line > > > with the general TinkerPop direction. > > > > > > > > > > 2) Pardon my ignorance, but can you share the Javadocs for the remote > > > > traversals API, as I'm not familiar with it? I can then evaluate > whether I > > > > can > > > > support that or not. Also, can you elaborate what you meant when you > said > > > > "elements don't hold properties"? When I look at the core Vertex, > Edge, and > > > > Element interfaces, it does hold properties. > > > > > > > > > > I'm talking about GLVs and remoting: > > > > > > http://tinkerpop.apache.org/docs/current/reference/# > connecting-via-remotegraph > > > http://tinkerpop.apache.org/docs/current/reference/#gremlin-python > > > > > > there should be another link here for gremlin-dotnet but we're > struggling > > > with doc generation atm, but hopefully you get the idea. your examples > > > seemed to require an embedded Graph instance, whereas remoting enables > > > traversals to be converted to bytecode, shipped to gremlin server, with > > > results returned from there (i.e. the Graph instance isn't embedded but > > > remote). Key to this point is that when you do g.V() with remoting you > > > don't get back properties. You get back a "reference" vertex which > only has > > > the id and label - no properties. We've come to agree that not > returning > > > properties is important for a number of reasons, not the least of > which is > > > multi-properties - imagine you returned a vertex with a million > properties > > > on it. > > > > > > 3) I share your concern that if we had to port this across languages, > it > > > > would > > > > be a non-trivial task (even without the comments, its 2905 lines of > main > > > > code, > > > > and 2354 lines of test code). Having said that, if we were to assume > that > > > > the > > > > GLV is supported through JSR-223, then there's a chance that > > > > gremlin-objects > > > > will work for that GLV. I'll try and do a proof of concept for that > in the > > > > separate > > > > project specifically for Gremlin-Python. > > > > > > > > > > Yes - I would think that JVM projects could make use of > gremlin-objects. > > > It's one of the reasons we don't have gremlin-scala or Ogre in > TinkerPop. > > > Those languages can all easily work with existing TinkerPop Java > libraries > > > as their cornerstone. Gremlin-Python exists in TinkerPop as we wanted > to > > > support Python natively - i don't think many folks want to run python > in > > > the jvm. > > > > > > 4) The intent of this module wasn't to compete with the DSL paradigm. I > > > > believe > > > > that the two can co-exist. Let me try and illustrate that with this > > > > example: > > > > List<Friend> friends = query.by( > > > > g -> g.V().find(marko).friends(4)).list(Friend.class); > > > > where, "g" was obtained through graph.traversal( > > > > FriendsTraversalSource.class); > > > > Again, the module focuses on object mapping, and gets out of the way > when > > > > you want to specify traversals. It does provide a library of helper > > > > traversal > > > > functions based on objects, but again, it complements rather than > competes. > > > > > > > > > > I guess I could see that I suppose. I didn't have anything in mind in > > > particular when I wrote that. I think I'd just want to be sure we > always > > > have "less ways of doing things" rather than "more". TinkerPop > sometimes > > > produces too many ways to do the same thing and it causes confusion and > > > almost always leads to people doing things we didn't intend. > > > > > > > > > > Again, thanks for sharing your feedback - it was very valuable for > me. > > > > Once I > > > > incorporate some of the suggestions and concerns into my module, I'll > > > > publish > > > > the lin, and hopefully you can put it up on TinkerPop home page. I'm > > > > looking > > > > forward to seeing this gaining traction, and adding support for it, > as > > > > needed. > > > > > > > > > Sure - our listing policy is here: > > > > > > http://tinkerpop.apache.org/policy.html > > > > > > I think that you satisfy most of that - I think you just need an > official > > > release published to get listed. Just send an email to this list > letting us > > > know that you meet the policy requirements and would like to be added. > I > > > think your project will make a nice contribution the wider TinkerPop > > > Community. > > > > > > Stephen > > > > > > > > > > > > On Tue, Aug 15, 2017 at 1:05 PM, Karthick Sankarachary < > [email protected]> > > > wrote: > > > > > > > Hi, Stephen, > > > > > > > > Thank you for sharing your feedback on my pull request. In > hindsight, I > > > > should > > > > have vetted this idea on the dev list first, and I apologize for > that. As > > > > suggested, > > > > I'll let gremlin-objects develop on it's own, and see if gains any > > > > traction. > > > > > > > > Before I publish that stand-alone project, I'd like to take this > > > > opportunity to > > > > address some of the concerns you brought up, if I may: > > > > > > > > 1) While it does introduce new object-centric Graph and Query > interfaces, > > > > the goal there was to simply facilitate the object-gremlin mapping. > The > > > > traversals are specified as lambdas, such as `g -> g.V().count()` or > > > > `traversal -> traversal.count()`, etc. As far as the provider > interface, I > > > > think I might be able to get rid of it, on second thoughts. All I > really > > > > need > > > > is a GraphTraversalSource. I may have to get rid of the ability to > execute > > > > scripts (traversals inside strings), but that'd be a small price to > pay. > > > > > > > > 2) Pardon my ignorance, but can you share the Javadocs for the remote > > > > traversals API, as I'm not familiar with it? I can then evaluate > whether I > > > > can > > > > support that or not. Also, can you elaborate what you meant when you > said > > > > "elements don't hold properties"? When I look at the core Vertex, > Edge, and > > > > Element interfaces, it does hold properties. > > > > > > > > 3) I share your concern that if we had to port this across > languages, it > > > > would > > > > be a non-trivial task (even without the comments, its 2905 lines of > main > > > > code, > > > > and 2354 lines of test code). Having said that, if we were to assume > that > > > > the > > > > GLV is supported through JSR-223, then there's a chance that > > > > gremlin-objects > > > > will work for that GLV. I'll try and do a proof of concept for that > in the > > > > separate > > > > project specifically for Gremlin-Python. > > > > > > > > 4) The intent of this module wasn't to compete with the DSL > paradigm. I > > > > believe > > > > that the two can co-exist. Let me try and illustrate that with this > > > > example: > > > > List<Friend> friends = query.by( > > > > g -> g.V().find(marko).friends(4)).list(Friend.class); > > > > where, "g" was obtained through graph.traversal( > > > > FriendsTraversalSource.class); > > > > Again, the module focuses on object mapping, and gets out of the way > when > > > > you want to specify traversals. It does provide a library of helper > > > > traversal > > > > functions based on objects, but again, it complements rather than > competes. > > > > > > > > 5) I understand why you wouldn't want to pick any given OGM as the > standard > > > > one, given that you listed so many, some of which I haven't even > heard of, > > > > to > > > > be honest. > > > > > > > > Again, thanks for sharing your feedback - it was very valuable for > me. > > > > Once I > > > > incorporate some of the suggestions and concerns into my module, I'll > > > > publish > > > > the lin, and hopefully you can put it up on TinkerPop home page. I'm > > > > looking > > > > forward to seeing this gaining traction, and adding support for it, > as > > > > needed. > > > > > > > > Best Regards, > > > > Karthick Sankarachary > > > > https://www.linkedin.com/in/karthicksankarachary > > > > > > > > On 2017-08-15 05:33, Stephen Mallette <[email protected]> wrote: > > > > > Some of you may have noticed this PR: > > > > > > > > > > https://github.com/apache/tinkerpop/pull/693 > > > > > > > > > > It is for an object graph mapper. It is fairly large and, at a > glance, a > > > > > nicely developed body of work (docs, tests, javadoc, etc). As the > author > > > > > didn't bring this up on the dev list before issuing the PR, I'm > unsure of > > > > > their intentions, but I assume they would like gremlin-objects to > be the > > > > > standard OGM for TinkerPop. > > > > > > > > > > Without drilling too deeply, my immediate concerns with accepting > this > > > > into > > > > > the code base: > > > > > > > > > > 1. It promotes use of a method of development that seems in > competition > > > > to > > > > > the Traversal API rather than one that complements it. For > example, it > > > > adds > > > > > a new Query object and uses Structure API semantics. It also adds > new > > > > > interfaces for providers to implement if they want to support this > > > > feature. > > > > > 2. I'm not clear on how well this approach would support remote > > > > traversals > > > > > especially since we discourage Elements from being returned with > > > > > properties. > > > > > 3. The author admitted that this is a Java only solution. Given > the size > > > > > and complexity of this PR I'd be concerned about trying to > implement it > > > > > across languages. Our general design goal has been to keep GLVs > simple. > > > > > Recall again - elements in GLVs don't hold properties at all - > it's not > > > > > even an option. > > > > > 4.I tend to see DSLs and OGMs linked a bit in terms of what they > do. DSLs > > > > > are new - just one version old. I'd like to seem them develop a bit > > > > longer > > > > > and get some feedback on usage to see how they address users > problems for > > > > > writing Gremlin in their domains. > > > > > 5. If we accept this, we are saying that this approach to OGM (and > there > > > > > have been a number of them, Ferma, Peapod, Frames, etc.) is the > "right" > > > > way > > > > > and as of right now I'm not sure I'm willing to get behind that. I > tend > > > > to > > > > > think there are many ways to OGM and that different people will > like > > > > > different ways - this is largely the reason why we tend not to > focus our > > > > > development in this area. > > > > > > > > > > I think I'd like to see gremlin-objects develop on its own for a > while > > > > > separately, build its own community following, and work out > whatever > > > > rough > > > > > edges it may have. TinkerPop would add it to the tool listing on > the home > > > > > page and promote it as an option for those looking for an OGM. > We've had > > > > > this recommendation before to other pull requests and project > suggestions > > > > > and I think it tends to work out well for all parties. > > > > > > > > > > For those reading this not familiar with our processes, this is > just my > > > > > opinion on how we should move forward. Others may not feel this > way. > > > > Please > > > > > feel free to share your thoughts. > > > > > > > > > > Thanks, > > > > > > > > > > Stephen > > > > > > > > > > > > > > >
