[
https://issues.apache.org/jira/browse/CASSANDRA-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092151#comment-13092151
]
Eric Evans commented on CASSANDRA-2936:
---------------------------------------
Looking at this:
It doesn't seem as if the JDBC driver uses much outside of
{{o.a.c.db.marshal}}, and what it does boils down to the simplest bits, nothing
with dependencies (aside from the odd utility method):
* {{getString(Obj)}}
* {{toString()}}
* {{isCaseSensitive()}}
* {{getScale()}}
* {{getPrecision(arg)}}
* {{isCurrency()}}
* {{isSigned()}}
* {{getJdbcType()}}
What's killing it are things like the classes used to type the comparator
members in {{AbstractType}}:
{code:style=Java}
import org.apache.cassandra.db.IColumn;
import static org.apache.cassandra.io.sstable.IndexHelper.IndexInfo;
...
public final Comparator<IndexInfo> indexComparator;
public final Comparator<IndexInfo> indexReverseComparator;
public final Comparator<IColumn> columnComparator;
public final Comparator<IColumn> columnReverseComparator;
public final Comparator<ByteBuffer> reverseComparator;
{code}
That sets up a quagmire of transitive dependencies that ends up pulling in huge
chunks of the project.
It seems like there are two approaches to fixing this, (a) making the classes
in {{o.a.c.db.marshal}} more stand-alone by separating out the problematic
parts ("somehow"), or (b) separating the pieces useful to the JDBC driver
(marshaling to/from string, signed-ness, scale, precision, etc), and reusing as
necessary from the classes in {{o.a.c.db.marshal}}.
The latter seems more palatable, if only because it is less disruptive.
> improve dependency situation between JDBC driver and Cassandra
> --------------------------------------------------------------
>
> Key: CASSANDRA-2936
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2936
> Project: Cassandra
> Issue Type: Improvement
> Components: API, Core
> Affects Versions: 0.8.1
> Reporter: Eric Evans
> Priority: Minor
> Labels: cql
>
> The JDBC jar currently depends on the {{apache-cassandra-$version}} jar,
> despite the fact that it only (directly) uses a handful of Cassandra's
> classes. In a perfect world, we'd break those classes out into their own jar
> which both the JDBC driver and Cassandra (ala
> {{apache-cassandra-$version.jar}}) could depend on. However, the classes
> used directly don't fall out to anything that makes much sense
> organizationally (short of creating a
> {{apache-cassandra-misc-$version.jar}}), and the situation only gets worse
> when you take into account all of the transitive dependencies.
> See CASSANDRA-2761 for more background, in particular
> ([this|https://issues.apache.org/jira/browse/CASSANDRA-2761?focusedCommentId=13048734&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13048734]
> and
> [this|https://issues.apache.org/jira/browse/CASSANDRA-2761?focusedCommentId=13050884&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13050884])
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
