I suggest that, as a bare minimum, you log a JIRA case for the adapter that you want / are building. In that case you can describe the problem you are solving, and other people can find you and collaborate.
You can start developing the adapter in a Calcite branch. Make it a separate maven module (the Druid, Geode and Cassandra adapters follow that pattern). If It doesn’t progress to a PR that gets accepted into Calcite, you haven’t lost anything: you can still move the code elsewhere. But if the adapter starts gaining adoption, and other contributors, then you have a strong case for us to accept it. Added benefit: If you develop it in this way, you won’t need to go through IP clearance[1]. Julian [1] http://incubator.apache.org/ip-clearance/ > On Feb 14, 2019, at 8:25 AM, Michael Mior <[email protected]> wrote: > > There is no separate project which collects Calcite adapters. You will > find a few projects around with different adapters that haven't been > accepted into Calcite for various reasons (the author doesn't desire > to, it's unlikely to be broadly useful, etc.) In general, I'd say > we're always interested in accepting well-tested code that is expected > to be generally useful. > > The contribution of an adapter that no one else is likely to use may > not be accepted, partially because when any new code is added, we also > add the burden of maintaining that code. That said, even in that case, > there's nothing stopping contributors for maintaining adapters > external to the Calcite code base :) > > -- > Michael Mior > [email protected] > > Le jeu. 14 févr. 2019 à 04:57, Hanan Yehudai > <[email protected]> a écrit : >> >> Hi all, >> we are developing a calcite based adapter, are there any pre-requirements >> to contribute it as part of calcite ? >> is there another Apache project for adapter ( like Baheer for Flink/ Spark >> sinks )? >> >>
