The problem with using 1 jar "everywhere" is that the client dependencies are more than the server ones. So to use the client you only need zookeeper and hadoop, but the server also needs JSP, JspC, etc, etc, things we'd rather not have our clients have to pull into their classpath.
Maybe we can publish a POM with a stripped down set of deps? Would that be a reasonable half solution? :-) -ryan On Thu, Apr 29, 2010 at 2:43 PM, Jonathan Gray <jg...@facebook.com> wrote: > 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.fran...@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 >
