Hi Julian, Thanks for the quick answer.
Looking at SqlFunctions in master branch, it depends on various libraries including avatica and linq4j, and also refers outside of runtime package of calcite. I could copy that classes and transitive imported classes as well, but I'm not sure other projects were doing same things. If calcite project maintains calcite-runtime module with smallest dependencies that would be awesome for users. I'm trying to avoid adding calcite-core as dependency since it depends on Guava, the problematic thing of dependency hell. Thanks, Jungtaek Lim (HeartSaVioR) On Saturday, August 6, 2016, Julian Hyde <[email protected]> wrote: > We didn’t really consider this when we designed Storm - Calcite > integration. But the good news is that SqlFunctions is a smallish class > with almost no dependencies. It, along with the rest of the > org.apache.calcite.runtime package, could in principle be copied into > Storm. (I’m not keen on creating a new calcite-runtime.jar but I could be > persuaded if someone made a strong case.) > > > On Aug 5, 2016, at 12:34 AM, Jungtaek Lim <[email protected] > <javascript:;>> wrote: > > > > Hi devs, > > > > I'm newbie of Calcite so I'd first say sorry for the ignorance if it's > > newbie question. > > > > I'm working on Storm SQL which uses Calcite to compile SQL to topology. > > Current implementation uses SqlFunctions to cover some operators so > > calcite-core and transitive dependencies are needed even though compiled > > topology in runtime. > > > > So I'd like to see what's preferred way of handling this. Is it common to > > add calcite-core to dependency in runtime, or is it common for individual > > projects to have their own similar classes? > > > > Thanks in advance, > > Jungtaek Lim (HeartSaVioR) > > -- Name : Jungtaek Lim Blog : http://medium.com/@heartsavior Twitter : http://twitter.com/heartsavior LinkedIn : http://www.linkedin.com/in/heartsavior
