Ron, I’ll attempt to answer but I might have misunderstood your use case. So if I am off the mark, please describe the architecture you want in more detail.
Let’s suppose you have a NoSQL database X and your application wants to speak SQL to it. You would include three Calcite modules: core, avatica, and the module for database X. The adapter for each database tends to be in a separate module (mongodb, spark, splunk, csv). JDBC is in core, but doesn’t bring in any dependencies. Core doesn’t contain dependencies on third-party systems. It does depend on things needed by the core functionality, for example Jackson, because we want people to be able to write their models in JSON. Reading pom.xml, the runtime dependencies of core are as follows: * calcite-apatica * protobuf * jackson * calcite-linq4j * commons-dbcp * findbugs-jsr305 * guava * eigenbase-properties * janino * pentaho-aggdesigner-algorithm I don’t think any of those has significant downstream dependencies. I’m very happy to have a discussion of what should be in core, and what its dependencies should be. There’s no “perfect” decomposition of a project into modules, but we can get a little nearer to perfection if we listen to how people (such as you) are deploying the project in the real world. After all that, if core is too heavyweight, then maybe you want *remote* Calcite rather than *embedded* Calcite. On your client you can include JUST avatica. On your server you would run avatica-server and include avatica and core and anything else you desire. Avatica has extremely low dependencies - you need either Jackson or Protobuf (depending on how you are encoding the RPCs). We didn’t even include Guava, even though we lean heavily on it elsewhere in Calcite. Julian > On Jan 24, 2016, at 7:18 PM, Ron Wheeler <[email protected]> > wrote: > > In the "marketing" videos, Calcite seems to be based on the idea that the > whole question of database access can be best solved by a modular approach. > I was surprised to see a lot of storage layer stuff mixed in with the core. > > I want to add an adapter and incorporate this into an application that has > its own database abstraction which currently supports Jackrabbit with an > in-memory configuration. > I can not afford to add a whole bunch of code and third party libraries that > are not essential. > > Is there a plan to produce a lightweight core package that is suitable for > use with an adapter? > > Ron > > -- > Ron Wheeler > President > Artifact Software Inc > email: [email protected] > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 >
