Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> Decision/Discussion about HBASE-2170: Lightweight client/Refactoring of source tree


Copy link to this message
-
Re: Decision/Discussion about HBASE-2170: Lightweight client/Refactoring of source tree
> I don't have a strong opinion on this, but find that the core of this problem seems to be a lack of simple documentation about the required jars to run a client.  The practice of adding jars until no longer getting CNFE would be solved with documentation stating which are client-dependent jars.

This would be the simplest solution, yes. I'm not sure if it is even
mentioned in the ticket ;-)

> What exactly is the goal?  Is it to prevent this CNFE trial-and-error practice?  Is it to make it so clients only need a single jar? ��Or is it to make a single, lightweight jar that only works for the client?

The goal would be to make developing applications that use HBase
easier. An extended goal would be to make it easier for those using
Maven. At the moment you can depend on the SNAPSHOT libraries that we
publish now to the repositories. But those have a complete set of
dependencies even for all the server stuff that is not needed on the
server side.

> Is there a lot of added value by having a single, client-only jar vs a single jar that works for client and server?

I can only talk from my personal experience (and the improved
documentation you mentioned would also have sufficed to a point) but
this separation would have made my start in HBase a lot easier because
there is no clear separation between the client and server and the
documentation is lacking.

I also regularly read this question on IRC, the user mailing list or
Twitter. So I'm definitely not alone.

> I'm all for making it easier for users, so if users say this would be helpful then we should do something.  Code separation is also not a bad thing.  I just never liked the hadoop separation so I don't want to make things actually more complex in the process.

What don't you like about the separation?
As mentioned in the ticket something like: hbase-common, hbase-server
and hbase-client would lend itself to what we've planned.

All in all I don't really have a strong opinion either way - it'd be
just nice to get a decision on this.

Cheers,
Lars
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB