So to summarize the problems with the original move, 1) the git problem
2) the JDBC build problems 3) the cqlsh problem In reverse order: The cqlsh problem is not the same as the JDBC problem. The cqlsh problem is simply, "if we have a cql shell that we ship, it would be convenient to have the driver there in the tree already." In other words, we have the same problem whether we have a Python cqlsh or a Java one. 3010 is a red herring. The JDBC problems can be subdivided into two categories: too-tight coupling that having it in-tree masks (but is really a problem either way), and java build systems being a PITA. By the second part I mean, yes, we had JDBC building after the first month or so, but it still required that the main Cassandra source tree be checked out and built locally, with a cumbersome manual process to point the driver build to it. The build headache is actually a symptom of the coupling. None of the other drivers have this problem; they were forced to do things "right"* instead of re-using things that shouldn't be re-used. If we were going to take another stab at it we should fix this first. (More accurately, we should fix it anyway whether we move drivers or not.) The git mirror is also a symptom of a deeper problem. Managing the drivers from the same Jira system as core is awkward too. Nor does three-day release voting or patch-oriented development feel like a good fit for CQL drivers. If we're going to move the drivers out-of-tree, why not move them all the way to github? We'll still be able to link "official" drivers from cassandra.apache.org, so I'm not worried about the kind of fragmentation we have with Thrift clients today. But if we want a little more official-ness, we could use Apache Extras on google code instead. Which IMO has better bug tracker and code review systems, but I don't really have strong feelings either way. So, of the problems with the original move, the cqlsh "problem" is the only one that by definition can't be solved if we move the drivers out of tree. I'm not enthusiastic about inflicting that on ourselves in exchange for problems with the git mirror. But in exchange for a clean separation as a separate project? That makes more sense to me.** * actually, relying on manual updating of Thrift is definitely suboptimal, but we've gotten away with it since the Thrift API hasn't been changing much. A better solution might use an svn:external reference to the interface/ directory. Not sure what we can do other than copy the .thrift file if we move to git though. ** And yes, I do remember arguing for keeping them in-project originally. Mea culpa. On Wed, Aug 24, 2011 at 7:22 PM, Eric Evans <eev...@acunu.com> wrote: > There's been discussion happening in #2761 > (https://issues.apache.org/jira/browse/CASSANDRA-2761) on and off now > for more than 3 months, and I think it could benefit from some wider > exposure. > > The issue was created in the wake of the driver move from > asf/cassandra/trunk/drivers to asf/cassandra/drivers and the original > scope was to create a working build for the JDBC driver post-move (at > the time it had no build of its own). That work has since been > completed, but it was left open to include some related items, in > hindsight it should have been closed and other issues opened as > needed. > > The remainder of the discussion that's taken place in CASSANDRA-2761 > revolves around moving the driver code back under Cassandra's tree. > > I don't want this to happen because, as I've mentioned elsewhere, > drivers are supposed to be coded to a specification, not a Cassandra > version; Any given driver release is expected to work with any version > of Cassandra that uses a CQL version >= to that of the driver. As > such there is a need to release them independently, with their own > versions, on a more or less frequently basis than Cassandra does. To > this point I think there is agreement. > > Where we disagree I guess is in how to accomplish this. > > Moving the driver has made things less convenient in part because in > it's current location it isn't mirrored by git.apache.org, and in part > because it's quite obviously less convenient than having everything > all in one monolithic tree. Most often cited for the latter is #3010 > (https://issues.apache.org/jira/browse/CASSANDRA-3010), an issue > opened to create a CQL-based shell written in Java. > > The lack of Git mirroring is unfortunate, but shouldn't be a blocker > IMO since the equivalent could be accomplished using git-svn. I would > however be willing to do this once, for everyone, and publish the > result on Github if that would help. > > As for cases like #3010, these are applications and it's no more or > less convenient than it would be for any other application. If the > JDBC driver is unsuitable for use by us as a dependency, then it's > unsuitable for our users as well. My suggestion here was to do what > we do with every other dependency we have and store a jar in lib/. > > There are some workarounds that have been proposed for moving the > drivers back under Cassandra's source tree while creating independent > releases from there. For example, keeping them only in trunk/ and > deleting drivers/ in new branches (which doesn't solve the case for > #3010). In my opinion, these are half-measures that fail to create > the needed separation while making the release process brittle, or > complicated, or both, and generate confusion (which incidentally is > exactly why they were moved in the first place). > > One other point that seems relevant is that all of the discussion has > centered around the JDBC driver only. If we were to eliminate it from > the equation, it appears there'd be no (or at least a lot less) > opposition to the move. This seems to reinforce the idea that we're > special-casing our own uses. > > Thoughts? Suggestions? > > -- > Eric Evans > Acunu | http://www.acunu.com | @acunu > -- Jonathan Ellis Project Chair, Apache Cassandra co-founder of DataStax, the source for professional Cassandra support http://www.datastax.com
