[
https://issues.apache.org/jira/browse/CASSANDRA-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051138#comment-13051138
]
Eric Evans commented on CASSANDRA-2761:
---------------------------------------
{quote}
The point is there are lots and they are scattered all over the various
packages; It will be very difficult to manage when they change from the driver
package (client side), which is supposed to be able to change independent of
the server code. If a subset of the server code is to be a dependency then that
subset (jar/s) must be managed in the main build not the driver build.
{quote}
Right, I was curious to see the list of classes (that list is fantastic btw,
thanks for that), to see if there was one point in the graph where breaking a
dependency would drastically change the scope of the problem. It looks like
the answer is Yes, and the dependency is {{o.a.c.config.CFMetaData}}, (needed
by {{ColumnDecoder}}).
Just skimming through the code, I don't think it would be hard to either
re-implement the needed parts of CFMetaData, or refactor CFMetaData to limit
what it pulled in.
> JDBC driver does not build
> --------------------------
>
> Key: CASSANDRA-2761
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2761
> Project: Cassandra
> Issue Type: Bug
> Components: API
> Affects Versions: 1.0
> Reporter: Jonathan Ellis
> Assignee: Rick Shaw
> Fix For: 1.0
>
> Attachments: jdbc-driver-build-v1.txt
>
>
> Need a way to build (and run tests for) the Java driver.
> Also: still some vestigal references to drivers/ in trunk build.xml.
> Should we remove drivers/ from the 0.8 branch as well?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
