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
