hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nigel Daley <nda...@yahoo-inc.com>
Subject Re: Developing cross-component patches post-split
Date Thu, 02 Jul 2009 06:58:58 GMT

On Jul 1, 2009, at 10:16 PM, Todd Lipcon wrote:

> On Wed, Jul 1, 2009 at 10:10 PM, Raghu Angadi <rangadi@yahoo- 
> 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 command line parameters for Ivy, the hdfs and mapreduce  
builds can depend on the latest Common build from one of:
a) a local filesystem ivy repo/directory (ie. a developer build of  
Common that is published automatically to local fs ivy directory)
b) a maven repo (ie. a stable published signed release of Common)
c) a URL

Option c can be a stable URL to that last successful Hudson build and  
is in fact what all the Hudson hdfs and mapreduce builds could be  
configured to use.  An example URL would be something like:

http://hudson.zones.apache.org/hudson/job/Hadoop-Common-trunk/lastSuccessfulBuild/artifact/

...

Giri is creating a patch for this and will respond with more insight  
on how this might work.

> This seems slightly better than actually committing the jars.  
> However, what
> should we do when the nightly build has failed hudson tests? We seem  
> to
> sometimes go weeks at a time without a "green" build out of Hudson.

Hudson creates a "lastSuccessfulBuild" link that should be used in  
most cases (see my example above).  If Common builds are failing we  
need to respond immediately.  Same for other sub-projects.  We've got  
to drop this culture that allows failing/flaky unit tests to persist.

>>
>> HDFS could have a build target that builds common jar from a  
>> specified
>> source location for common.
>>
>
> This is still my preffered option. Whether it does this with a  
> <javac> task
> or with some kind of <subant> or even <exec>, I think having the  
> source
> trees "loosely" tied together for developers is a must.

-1.  If folks really want this, then let's revert the project split. :-o

Nige


Mime
View raw message