On Jul 1, 2009, at 10:16 PM, Todd Lipcon wrote:
On Wed, Jul 1, 2009 at 10:10 PM, Raghu Angadi inc.com> wrote:
-1 for committing the jar.
Most of the various options proposed sound certainly better.
Can build.xml be updated such that Ivy fetches recent (nightly)
build?
+1. Using ant co
On Wed, Jul 1, 2009 at 8:09 PM, jason hadoop wrote:
> It is a bug fix,
It removes an undocumented limitation. *sigh*
If I remember right, that patch breaks compatibility. If so, I'd vote
against putting it into any of the release branches.
-- Owen
On Wed, Jul 1, 2009 at 6:45 PM, Todd Lipcon wrote:
> Agree with Phillip here. Requiring a new jar to be checked in anywhere after
> every common commit seems unscalable and nonperformant. For git users this
> will make the repository size baloon like crazy (the jar is 400KB and we
> have around 530
>
> For example,
> ant test
> does the same as it does now, but
> ant -Dhadoop.common.jar=/home/dhruba/common/hadoop-common.jar test will
> pick up the common jar from my home directory.
+1; we'll also need the same sort of thing for the daemons.
Regardless of whether or not jars are checked i
Raghu Angadi wrote:
Can build.xml be updated such that Ivy fetches recent (nightly) build?
HDFS could have a build target that builds common jar from a specified
source location for common.
+1 This is the standard way to go. Ivy can fetch the latest nightly
build or from the last successful
On Wed, Jul 1, 2009 at 10:10 PM, Raghu Angadi wrote:
>
> -1 for committing the jar.
>
> Most of the various options proposed sound certainly better.
>
> Can build.xml be updated such that Ivy fetches recent (nightly) build?
>
This seems slightly better than actually committing the jars. However,
On Wed, Jul 1, 2009 at 10:11 PM, Dhruba Borthakur wrote:
> Hi Todd,
>
> Another option (one that is used by Hive) is to have an ant macro that can
> be overridden from the ant command line. This macro points to the location
> of the common.jar. By default, it is set to the same value as it is now
-1 for committing the jar.
Most of the various options proposed sound certainly better.
Can build.xml be updated such that Ivy fetches recent (nightly) build?
HDFS could have a build target that builds common jar from a specified
source location for common.
Raghu.
Todd Lipcon wrote:
On Wed
Hi Todd,
Another option (one that is used by Hive) is to have an ant macro that can
be overridden from the ant command line. This macro points to the location
of the common.jar. By default, it is set to the same value as it is now. If
a developer has a common jar that is built in his/her directory
It is a bug fix, it fixes the mapside join to work as documented instead of
having an undocumented failure case when you have more than 32 tables in
your join statement.
On Wed, Jul 1, 2009 at 5:40 PM, Nigel Daley wrote:
> HADOOP-5589 is not a bug fix so it shouldn't go into branch-0.19.
>
> Nig
On Wed, Jul 1, 2009 at 2:10 PM, Philip Zeyliger wrote:
> -1 to checking in jars. It's quite a bit of bloat in the repository (which
> admittedly affects the git.apache folks more than the svn folks), but it's
> also cumbersome to develop.
>
> It'd be nice to have a one-liner that builds the equi
HADOOP-5589 is not a bug fix so it shouldn't go into branch-0.19.
Nige
On Jul 1, 2009, at 7:49 AM, jason hadoop wrote:
Can you put http://issues.apache.org/jira/browse/HADOOP-5589 in
please?
On Wed, Jul 1, 2009 at 2:44 AM, Tom White wrote:
I have created a candidate build for Hadoop 0.
extend DistributedCache to work locally (LocalJobRunner) (common half)
--
Key: HADOOP-6125
URL: https://issues.apache.org/jira/browse/HADOOP-6125
Project: Hadoop Common
Issu
Hi.
My 5 cents about svn:externals.
I could not live without it but...I always tend to forget to update our
svn:externals and about once a month I wonder why I accidentally released
bleeding edge code in our production environent *smile* (should've written
that auto-branching script waaay back ago
>
> - When we have one of these cross-project changes, how are we supposed to
>> do
>> builds?
>>
>
> I talked with Owen & Nigel about this, and we thought that, for now, it
> might be reasonable to have the mapreduce and hdfs trunk each contain an svn
> external link to the current common jar. T
Todd Lipcon wrote:
>> If someone could write up some kind of "post-split transition guide"
>> on the Wiki I think that would be generally appreciated.
Here's something I wrote up for re-setting up Eclipse after the split in
a way that gives relatively seamless access to the various projects'
so
Todd Lipcon wrote:
- Whenever a task will need to touch both Common and one of the components
(Mapred/HDFS) should there be two JIRAs or is it sufficient to have just one
"HADOOP" JIRA with separate patches uploaded for the two repositories?
Two Jiras, I think. In the long run, such issues sho
Hey all,
I think there's general confusion right now about how the development
process is supposed to work now that the project split has taken place. Or,
at least, I am generally confused :) Here are a couple questions I have
lingering:
- Whenever a task will need to touch both Common and one of
Sorry, please disregard this message - I've sent it to the wrong lists.
On 7/1/09 1:04 PM, Konstantin Boudnik wrote:
Thunderbird and Mutt are at least two which does thread JIRA's threads properly.
The way they do so is by using Message-ID and In-Reply-To fields of a RFC-822
header.
Cos
On 6/2
Thunderbird and Mutt are at least two which does thread JIRA's threads properly.
The way they do so is by using Message-ID and In-Reply-To fields of a RFC-822
header.
Cos
On 6/29/09 11:31 PM, Sharad Agarwal (JIRA) wrote:
[
https://issues.apache.org/jira/browse/HADOOP-6120?page=com.atlas
Hi everyone,
Is it possible to configure Hadoop's TaskTracker in a way that it
shutdown itself once being idle (no task to run) for a configurable
amount of time? I guess it
is not possible in current implementation. This feature is very useful
in situations (like of ours) where a MapReduce jobs
+1
cascading unit/regression tests pass
thanks Tom!
ckw
On Jul 1, 2009, at 2:44 AM, Tom White wrote:
I have created a candidate build for Hadoop 0.19.2. This fixes 42
issues in 0.19.1
(http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/fiel
Can you put http://issues.apache.org/jira/browse/HADOOP-5589 in please?
On Wed, Jul 1, 2009 at 2:44 AM, Tom White wrote:
> I have created a candidate build for Hadoop 0.19.2. This fixes 42
> issues in 0.19.1
> (
> http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&so
I have created a candidate build for Hadoop 0.19.2. This fixes 42
issues in 0.19.1
(http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&pid=12310240&fixfor=12313650).
*** Please download, test and vote before the
*** vote closes on
See http://hudson.zones.apache.org/hudson/job/Hadoop-Patch-vesta.apache.org/540/
--
started
Building remotely on vesta.apache.org (Ubuntu)
Location 'http://svn.apache.org/repos/asf/hadoop/core/trunk' does not exist
Location could be expanded on build 'Hadoop
25 matches
Mail list logo
