Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-dev@hadoop.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <4A4BCCEA.3000604@apache.org>
References: <45f85f70907011344t5e2e4fd8nf31800aa30797ac7@mail.gmail.com>
	<4A4BCCEA.3000604@apache.org>
From: Philip Zeyliger <philip@cloudera.com>
Date: Wed, 1 Jul 2009 14:10:04 -0700
Message-ID: <15da8a100907011410l2ad4c4afq5b05a488240433cf@mail.gmail.com>
Subject: Re: Developing cross-component patches post-split
To: common-dev@hadoop.apache.org
Content-Type: multipart/alternative; boundary=000e0cd25b90084e48046dab5ab5

--000e0cd25b90084e48046dab5ab5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

>
>  - 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.  Then folks can commit new versions
> of hadoop-common-trunk.jar as they commit changes to common's trunk.  We'd
> need to remove or update this svn external link when branching.  Thoughts?


-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 equivalent of the tarball
built by "ant binary" in the old world.  When you're working on something
that affects both common and hdfs, it'll be pretty painful to make the jars
in common, move them over to hdfs, and then compile hdfs.

Could the build.xml in hdfs call into common's build.xml and build common as
part of building hdfs?  Or perhaps have a separate "top-level" build file
that builds everything?

-- Philip

--000e0cd25b90084e48046dab5ab5--