The coprocessor and filter classes are a very thin veneer over the
classes that actually do the bulk of the work (Expression and
ResultIterator for example). Once we have our query server, then the
client side will be smaller and self contained.

On Thu, Mar 26, 2015 at 6:35 PM, Jesse Yates <[email protected]> wrote:
>> if the latter, it's because we don't have one right now,
> which I think is a mistake in our pom structure.
>
> As in, you think the client code needs to be separated from the server code
> so that you need less stuff on the client? Yes, totally.. but its not
> trivial to get there :)
>
> And has it really gained HBase that much?
>
> On Thu, Mar 26, 2015 at 6:27 PM Nick Dimiduk <[email protected]> wrote:
>
>> Are you meaning the client uberjar, like what we use from sqlline.py, or a
>> regular jar, as is done in the case of hbase-client? In the former case, we
>> don't do this because publishing uberjars on maven central is discouraged
>> (forbidden?). If the latter, it's because we don't have one right now,
>> which I think is a mistake in our pom structure.
>>
>> See also PHOENIX-1567.
>>
>> -n
>>
>> On Thu, Mar 26, 2015 at 5:57 PM, Mujtaba Chohan <[email protected]>
>> wrote:
>>
>> > See this related thread
>> >
>> > http://mail-archives.apache.org/mod_mbox/incubator-phoenix-
>> user/201409.mbox/%3CCAAF1JdiEMCFpt6epppJ+x_fDMd7RcX3f1sTbbbbHuPtd+hqjww@
>> mail.gmail.com%3E
>> >
>> > On Thu, Mar 26, 2015 at 5:42 PM, Devaraj Das <[email protected]>
>> wrote:
>> >
>> > > ?Hi, someone was asking me today why isn't there a phoenix-client (akin
>> > to
>> > > hbase-client) in the maven repo. I couldn't explain and thought of
>> asking
>> > > here... Am curious to know if there was any technical reasoning behind
>> > not
>> > > having that.
>> > >
>> > > Thanks,
>> > >
>> > > Devaraj
>> > >
>> >
>>

Reply via email to