hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tsz Wo Sze <szets...@yahoo.com>
Subject Re: Putting the hdfs client as a separate jar
Date Wed, 02 Apr 2014 21:48:41 GMT
It is a very good idea although it might not be easy to do.  One aspect to consider is that
do we need separated jars for rpc client and web client?  Now, suppose we could successfully
separate HFDS Client jar(s) from HDFS.  However, HDFS Client uses Common as a library.  We have
to separate Common since it also has a lot of dependent jars.  I guess we might have to
divide Common and HDFS into small modules and figure out the dependency between them.

Tsz-Wo
On Wednesday, April 2, 2014 2:28 PM, Haohui Mai <hmai@hortonworks.com> wrote:
 
Hi,
>
>Many downstream projects needs the ability to access hdfs. In order to do
>this, currently downstream projects are forced to bring in the whole hdfs
>jar and its dependency, since both the hdfs server and the hdfs client
>reside in the same jar.
>
>To integrate with hdfs, the downstream projects are forced to manage the
>excess dependency from the hdfs server side (e.g., jersey, servlet, netty,
>and jsp-runtime, just to name a few). In my own experience, I ended up
>spending quite a bit of time on tweaking the POMs to work around collisions
>of dependent jars.
>
>To solve this problem, I propose to reorganize the code to put hdfs client
>into a separate jar. That way the client jar no longer depends on the jars
>that are required by the server side, therefore it is easier for the
>downstream projects to integrate with hdfs.
>
>Your feedbacks are appreciated.
>
>Regards,
>Haohui
>
>-- 
>CONFIDENTIALITY NOTICE
>NOTICE: This message is intended for the use of the individual or entity to 
>which it is addressed and may contain information that is confidential, 
>privileged and exempt from disclosure under applicable law. If the reader 
>of this message is not the intended recipient, you are hereby notified that 
>any printing, copying, dissemination, distribution, disclosure or 
>forwarding of this communication is strictly prohibited. If you have 
>received this communication in error, please contact the sender immediately 
>and delete it from your system. Thank You.
>
>
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message