hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bharath Mundlapudi <bharathw...@yahoo.com>
Subject Re: 0.23 & trunk tars, we'll we publishing 1 tar per component or a single tar? What about source tar?
Date Fri, 14 Oct 2011 18:58:08 GMT
Other approach would be asking which tar to build.

mapred-tar (mapred and common)
hdfs-tar (hdfs and common)
hadoop-tar (all)

In this case, hbase can just use hdfs-tar.

-Bharath



________________________________
From: Ravi Teja <raviteja@huawei.com>
To: mapreduce-dev@hadoop.apache.org; common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org
Sent: Wednesday, October 12, 2011 9:43 PM
Subject: RE: 0.23 & trunk tars, we'll we publishing 1 tar per component or a single tar?
What about source tar?

I feel #4 as a better option.

Regards,
Ravi Teja

-----Original Message-----
From: Alejandro Abdelnur [mailto:tucu@cloudera.com] 
Sent: Wednesday, October 12, 2011 9:38 PM
To: common-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org;
hdfs-dev@hadoop.apache.org
Subject: 0.23 & trunk tars, we'll we publishing 1 tar per component or a
single tar? What about source tar?

Currently common, hdfs and mapred create partial tars which are not usable
unless they are stitched together into a single tar.

With HADOOP-7642 the stitching happens as part of the build.

The build currently produces the following tars:

1* common TAR
2* hdfs (partial) TAR
3* mapreduce (partial) TAR
4* hadoop (full, the stitched one) TAR

#1 on its own does not run anything, #2 and #3 on their own don't run. #4
runs hdfs & mapreduce.

Questions:

Q1. Does it make sense to publish #1, #2 & #3? Or #4 is sufficient and you
start the services you want (i.e. Hbase would just use HDFS)?

Q2. And what about a source TAR, does it make sense to have source TAR per
component or a single TAR for the whole?


For simplicity (for the build system and for users) I'd prefer a single
binary TAR and a single source TAR.

Thanks.

Alejandro
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message