Good point. I went ahead and created two releases, corresponding to TinkerPop 
3.2.5
and TinkerPop 3.3.0-SNAPSHOT:

https://github.com/karthicks/gremlin-ogm/releases

The two versions are essentially the same, except for the TinkerPop version 
that they
depend on.

Regards,
Karthick

On 2017-08-17 04:41, Stephen Mallette <[email protected]> wrote: 
> 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
> > > > > >
> > > > >
> > > >
> > >
> >
> 

Reply via email to