> 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
