incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: Helping Neo4j Release an Apache2 API for Apache Projects
Date Wed, 13 May 2015 08:16:51 GMT
neo4j is just a remote app in this context, right? So there'll be no classpath contamination?

in which case, I don't see why there'd be any worry about pulling in to the test/release process.
I think having neo4j maintain the artifact makes sense from a maintenance/release process,
tinkerpop can just pull it in for the build, and perhaps the test. 

think about how much stuff we distribute which depends on a closed source product -anything
that works with, say, Amazon web services, or Oracle DB. the policy there has always been:
compatible code on the asf source, build, distribution; recipient gets to choose their actions.

> On 30 Apr 2015, at 16:33, Marko Rodriguez <> wrote:
> Hello,
> Here are notes to peoples comments thus far:
> 	1. TinkerPop2 (prior to Apache) maintained all the vendor connectors. This was very
burdensome for the TinkerPop developers as we had to stay up to date on each vendors changes.
We didn't want to go down this road for TinkerPop3 (now Apache).
> 	2. However, we are interested in providing two "reference implementations" of TinkerPop.
One for OLTP (Neo4j) and one for OLAP (Hadoop). We think providing Neo4j and Hadoop "out of
the box" is a good thing for TinkerPop as it provides other vendors code to look at ("ah,
thats how they did transactions for Neo4j -- okay, I will copy that pattern") and users a
starting point ("okay, lets load my data into Neo4j by following the examples in the docs.").
> 	3. Note that TinkerPop3 does NOT "depend" on Neo4j. neo4j-gremlin is simply a parallel
module that can be ":install"'d by the user if they want. If the user doesn't want it, its
not in their CLASSPATH, etc. Likewise for hadoop-gremlin. However, in our docs, we like to
show both Neo4j and Hadoop as it provides more context to TinkerPop -- not just, "here is
an API you can use, good luck." So, if a user is using, lets say, titan-gremlin, there is
NOTHING "Neo4j" in their CLASSPATH, <depedency/>, etc. TinkerPop doesn't NEED Neo4j.
> 	-- you can see how hadoop-gremlin requires an :install (not something that is part of
> 	4. TinkerPop is not trying to push Neo4j in order to boost Neo4j's worth in any way.
Realize that many of the TinkerPop contributors work for a Neo4j competitor (Titan (Aurelius)
-> DSE Graph (DataStax)). We are not here to play "money games" but to make sure the graph
community has graph technology. Neo4j is an easy, stable, popular graph database with a simple
<dependency/> and you are off.
> 	5. We planned on giving Neo4j neo4j-gremlin so they could release it as they wish. However,
this leaves a hole in our product as then we have hadoop-gremlin as a reference implementation
of OLAP, but no OLTP counterpart. This is sorta awkward. If we gutted neo4j-gremlin, we would
then want to gut hadoop-gremlin…. However, we really don't want to do that. We think having
these two connectors available with each release makes TinkerPop easier for users and vendors
to adopt TinkerPop.
> I hope this clears things up. Please ask more questions if not.
> Thank you,
> Marko.
> On Apr 30, 2015, at 3:35 AM, Bertrand Delacretaz <> wrote:
>> Hi,
>> On Tue, Apr 28, 2015 at 5:33 PM, Marko Rodriguez <> wrote:
>>> ...In short, TinkerPop would depend on an Apache2 licensed neo4j-api. Some manual
>>> downloads from testers/users would be required to use the tinkerpop-neo4j component
>>> with a Neo4j database....
>> That sounds ok to me as long as that's an optional component of TinkerPop.
>> -Bertrand
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message