Re: [DISCUSS] split metastore and service

2017-04-05 Thread Carl Steinbach
+1! On Tue, Mar 28, 2017 at 6:36 PM, Thejas Nair wrote: > Also, thanks for the email thread to bring peoples attention to this > change. > > On Tue, Mar 28, 2017 at 6:35 PM, Thejas Nair > wrote: > > > +1 > > Thanks for looking into this! > > > > > > On Tue, Mar 28, 2017 at 11:26 AM, Eugene Koif

Re: [DISCUSS] split metastore and service

2017-03-28 Thread Thejas Nair
Also, thanks for the email thread to bring peoples attention to this change. On Tue, Mar 28, 2017 at 6:35 PM, Thejas Nair wrote: > +1 > Thanks for looking into this! > > > On Tue, Mar 28, 2017 at 11:26 AM, Eugene Koifman > wrote: > >> +1 reduce the number of uber jars >> >> >> On 3/27/17, 1:05

Re: [DISCUSS] split metastore and service

2017-03-28 Thread Thejas Nair
+1 Thanks for looking into this! On Tue, Mar 28, 2017 at 11:26 AM, Eugene Koifman wrote: > +1 reduce the number of uber jars > > > On 3/27/17, 1:05 PM, "Sergey Shelukhin" wrote: > > Splitting the metastore would also allow us to get rid of compile time > dependencies that are resolved

Re: [DISCUSS] split metastore and service

2017-03-28 Thread Eugene Koifman
+1 reduce the number of uber jars On 3/27/17, 1:05 PM, "Sergey Shelukhin" wrote: Splitting the metastore would also allow us to get rid of compile time dependencies that are resolved via reflection right now. +1 on the feature On 17/3/27, 07:33, "Zoltan Haindrich" wrote:

Re: [DISCUSS] split metastore and service

2017-03-27 Thread Sergey Shelukhin
Splitting the metastore would also allow us to get rid of compile time dependencies that are resolved via reflection right now. +1 on the feature On 17/3/27, 07:33, "Zoltan Haindrich" wrote: >Hello, > >Currently the jdbc driver contains lots of hive code; which are not >needed for the driver to

[DISCUSS] split metastore and service

2017-03-27 Thread Zoltan Haindrich
Hello, Currently the jdbc driver contains lots of hive code; which are not needed for the driver to function properly - jdbc-standalone is currently a 60M binary! :) I've opened a ticket, to explore the possibilites what can be done in this aspect to reduce jdbc's dependencies. I was able to r