[
https://issues.apache.org/jira/browse/HCATALOG-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sushanth Sowmyan updated HCATALOG-589:
--------------------------------------
Affects Version/s: 0.5
> Dependent library packaging
> ---------------------------
>
> Key: HCATALOG-589
> URL: https://issues.apache.org/jira/browse/HCATALOG-589
> Project: HCatalog
> Issue Type: Improvement
> Affects Versions: 0.5
> Reporter: Sushanth Sowmyan
> Attachments: HCAT-589.patch
>
>
> 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
