Sushanth Sowmyan created HCATALOG-589:
-----------------------------------------
Summary: Dependent library packaging
Key: HCATALOG-589
URL: https://issues.apache.org/jira/browse/HCATALOG-589
Project: HCatalog
Issue Type: Improvement
Reporter: Sushanth Sowmyan
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).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
