Bringing together the Apache Cassandra experts from the community and DataStax.

Want to learn? Have a question? Want to share your expertise? You are in the right place!

Not sure where to begin? Getting Started

 

question

lrsundar avatar image
lrsundar asked Erick Ramirez edited

Why is OSS and DSE source code tightly coupled in the Java driver?

I see that we have two distinct sub-directories `oss` and `dse`. In spite of this segregation, code in both the modules refer to each other (import).

Is this by design? Will this ever change?

It would make sense to keep them separate, so their dependencies can be isolated. But, by mixing both of them together, it has been made impossible. I understand, we have the option via pom.xml to exclude modules not needed, but in certain cases having isolation is more helpful.

Thanks

PS: Only a few files in `oss` depend on `dse`. So, with a little effort, `oss` could be made independant.

A snapshot of the example below:-

$ grep -nr "import com.datastax.dse" .
./driver/internal/core/metrics/DropwizardSessionMetricUpdater.java:19:import com.datastax.dse.driver.api.core.config.DseDriverOption;
./driver/internal/core/metrics/DropwizardSessionMetricUpdater.java:20:import com.datastax.dse.driver.api.core.metrics.DseSessionMetric;
./driver/internal/core/metrics/DropwizardNodeMetricUpdater.java:19:import com.datastax.dse.driver.api.core.config.DseDriverOption;
./driver/internal/core/metrics/DropwizardNodeMetricUpdater.java:20:import
java driver
10 |1000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 1.0 MiB each and 10.0 MiB total.

1 Answer

alexandre.dutra avatar image
alexandre.dutra answered alexandre.dutra commented

Is this by design?

Yes. This is a direct consequence of the fact that the code under com.datastax.dse was originally released under a proprietary license, then was made available under the Apache license and incorporated into the driver-core module.

Will this ever change?

No, at least not until the next major version, because moving classes around is a breaking change.

PS: Only a few files in oss depend on dse. So, with a little effort, oss could be made independant.

When this code was imported the goal was exactly the opposite: users of Cassandra shouldn't have to deal with many modules, we wanted them to only deal with one single, one-stop-shop module: com.datastax.oss:java-driver-core.

Read more about this here.

2 comments Share
10 |1000 characters needed characters left characters exceeded

Up to 8 attachments (including images) can be used with a maximum of 1.0 MiB each and 10.0 MiB total.

Thanks for taking the time to respond.


>> No, at least not until the next major version, because moving classes around is a breaking change.

While it is great to see dse features percolating in to oss, it would be best this is done not by directly referring to dse packages from within oss. That way users of oss are not burdened to include a whole bunch of extra libs dse links to.

Please make sure, this refactor is in the agenda for the next major release, and it would be a great help to the community.

0 Likes 0 ·

I agree with you that DSE features pull in a whole bunch of transitive dependencies. It's not ideal, but at least you can remove them if don't need them: read here.

The right place for proprietary DSE dependencies is still under debate at DataStax, and the ASF has its word on this matter too. Nothing is decided yet, but it's possible that in the next major version, such proprietary code could be better isolated than it is today.

0 Likes 0 ·