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 <okramma...@gmail.com> 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 TinkerPop):
> http://tinkerpop.incubator.apache.org/docs/3.0.0.M8-incubating/#hadoop-gremlin
>
> 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.
>
> http://markorodriguez.com
>
> On Apr 30, 2015, at 3:35 AM, Bertrand Delacretaz <bdelacre...@apache.org>
> wrote:
>
>> Hi,
>>
>> On Tue, Apr 28, 2015 at 5:33 PM, Marko Rodriguez <okramma...@gmail.com>
>> 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: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
