hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Gray <jg...@facebook.com>
Subject RE: Decision/Discussion about HBASE-2170: Lightweight client/Refactoring of source tree
Date Thu, 29 Apr 2010 21:43:22 GMT
I just see the separation as added complexity.  Give me one jar and let me use it everywhere...
why do I care about the lines being drawn?

It doesn't seem to be the case that we're after anything "lightweight" at all.  It's more
about simplicity and ease of use.


Also, we're talking about stuffing dependent jars into the client jar (and server jar?). 
So if we want to upgrade zookeeper, for example, we regenerate new client/server hbase jars?
 How will this operate if we also have a zookeeper jar in the classpath outside the hbase
jar?


I think clear documentation with the way things currently work is a good way to go.  If there's
an additional way for people to execute a command and get a single, client jar which is self-contained,
then that could be helpful to them.  Perhaps we could ship with this jar as well?


Again, don't really feel that strongly either way.  I’m already uncomfortable enough with
maven in general and what it means for how we ship our releases (without dependencies), so
we do need to pick a direction and try to make it as easy/clear/documented as possible.

Thanks for continuing the conversation... other people's thoughts?

JG

> -----Original Message-----
> From: Lars Francke [mailto:lars.francke@gmail.com]
> Sent: Thursday, April 29, 2010 11:30 AM
> To: hbase-dev@hadoop.apache.org
> Subject: 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
Mime
View raw message