On Tue, Nov 14, 2017 at 2:58 PM, Rick Kellogg <rmkell...@comcast.net> wrote:
> Greetings, > > > > About a week ago, I opened a new JIRA ticket [HBASE-19207] - Create a > Minimal HBase REST Client. As I started to study the feasibility of this > task, I determined the project dependencies were a hornets nest. There is > no clear separation of client and server components. For example the > VersionModel class relies upon the javax.servlet.ServletContext class for > construction on the server. There are many other examples of blurred > boundaries. > > > Indeed. Separation of client and server, like the separation of church and state, ebbs and flows is a long way from being done. > > I initially tried to break out the client specific files plus protocol > buffer related files in the hbase-rest project. This lead me to believe we > could create a clear separation of client and server components. The > trouble started on how to provide access to classes such as Cell or Scan > from the hbase-client. Cell should be hbase-common; no need of the hbase-client dependency. Scan is another story. You need access to these Operation classes? > Using the hbase-shaded-client seems to be a solution > but far from ideal. This failed as well because of complications with > shading. The protocol buffer related stuff was generated twice. Once in > my > project and already in the hbase-shaded-client. > > Your project could not access the shaded classes inside hbase-client? Is the double-execution of shading an issue? (Perhaps you are saying that we shaded already-shaded classes?) This is great feedback though. Please dump the litany of your troubles into HBASE-19207 if you have a list. This will help with the aforementioned laggard separation project. > > So as an interim solution, I would like to suggest the introduction of a > Apache Maven Bill-of-Materials (BOM) for access to the HBase REST Client. > I > have created a BOM for 2.0.0-alpha4 on Github for comment: > > > > https://github.com/rmkellogg/hbase-rest-client-ex > > > > Using the BOM feature, I was able to reduce the number of dependencies from > 146 to 21. > > > Good. Let me comment up on github. Thanks for writing back to the dev list Richard, St > > I think we could allow some flexibility for upgrade to common libraries > (Guava, Apache HttpComponents, etc) using this technique. > > > > > Thoughts and comments appreciated. > > Rick Kellogg > > > >
