On Wed, Aug 24, 2011 at 17:22, 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. >
I don't think git mirroring should decide where we have the code, especially since most people build from tarballs. > 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). Some apache projects organize their code into multiple trunks, and that sounds like it would help us out here. > > 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? I'd like to see the drivers isolated from cassandra core. It's been months since I've analyzed what the dependencies were, but I remember them being centered around comparators. The truth is the comparators were bent to make some things more convenient for encoding/decoding in the JDBC driver, when that code should have been made common or just plain copied. If there are other dependencies, the work should be done to get them out. Bottom line: the JDBC driver needs to be changed so that it doesn't depend on cassandra core. Gary.
