Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
0.5
-
None
-
None
-
None
Description
During doing my e2e testing, I ran into issues because hcat depends on guava 11+, whereas only hive/lib provides only guava-r09. Since we depend on a newer version of guava, we should include it in our distribution packaging.
Then comes the issue of where to put in such a dependency. The standard we used to have before we cleaned up our dependencies was that hcat libraries themselves were in share/hcatalog/ and dependencies were in share/hcatalog/lib. I think that this is a reasonable practice to separate them out, since we want people who want only hcat libraries to be able to get them without the deps, and those that want the libraries and its deps, can get both directories.
So, ideally, I'd put guava.jar inside share/hcatalog/lib, whereas hcatalog.jar remains in share/hcatalog/. This way, we don't "pollute" share/hcatalog/
Now, normally, this would be trivial, and I'd just add it, but the reason I wanted to open a discussion on this is because we now have further components, such as the hbase storage handler, which also has an additional dependency on protobuf.jar. Now, if we were to follow the same logic as above, then the directory, then, given that the storage handler itself resides in share/hcatalog/storage-handlers/hbase/lib/, the equivalent place to put the protobuf jar is share/hcatalog/storage-handlers/hbase/lib/lib , which feels icky to me.
So.. ideas? preferences?
(In other news, I'll create another jira for this, but I believe we should clean up our directory structure of our packaging further by 0.6 timeframe - the whole share/hcatalog/ stuff is a relic from when we were trying to come up with a unified packaging structure that would work if a person were to minimally create a .rpm or .deb on it and dump these files wholesale into /usr, or if they used a HCAT_PREFIX structure. Given that we now have bigtop providing packaging on top of hcat, we can clean this up).