incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Helping Neo4j Release an Apache2 API for Apache Projects
Date Fri, 22 May 2015 05:28:07 GMT
Steve, (sorry for late reply)

Neo4j can either be remote or embedded, and my guess is that TinkerPop is
looking for the embedded variant, since (IIRC) that is under GPL whereas
"remote" is the Enterprise version which is either commercial or AGPL
license.

I think it is great that Neo is interested in releasing neo4j-api under
ALv2. They have talked about that for at least 6-7 years, and would be cool
in itself.

I think Tinkerpop needs to provide a non-GPL implementation to fulfill ASF
release requirements, and make Neo4j an optional choice, even if the
neo4j-api is under ALv2.

// Niclas

On Wed, May 13, 2015 at 4:16 PM, Steve Loughran <stevel@hortonworks.com>
wrote:

> 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 <okrammarko@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 <bdelacretaz@apache.org>
> wrote:
> >
> >> Hi,
> >>
> >> On Tue, Apr 28, 2015 at 5:33 PM, Marko Rodriguez <okrammarko@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-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message