On Jul 1, 2009, at 10:16 PM, Todd Lipcon wrote:
On Wed, Jul 1, 2009 at 10:10 PM, Raghu Angadi <rang...@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
