Mailing-List: contact mapreduce-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mapreduce-dev@hadoop.apache.org
Received-SPF: neutral (athena.apache.org: 216.145.54.173 is neither permitted
 nor denied by domain of evans@yahoo-inc.com)
From: Robert Evans <evans@yahoo-inc.com>
To: "mapreduce-dev@hadoop.apache.org" <mapreduce-dev@hadoop.apache.org>
Date: Fri, 19 Aug 2011 09:51:43 -0700
Subject: Re: Picking up local common changes in mr
Thread-Topic: Picking up local common changes in mr
Thread-Index: AcxejwqovfMO2BpNR7izkpztbSUSEAAATtcx
Message-ID: <CA73FECF.27A9E%evans@yahoo-inc.com>
In-Reply-To: 
 <CA+z3+9F7TC9-m1RnH4R_tA2k_vjtnpPX6RtuSTQ9cV_3J3bYBw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en
acceptlanguage: en-US
Content-Type: multipart/alternative;
	boundary="_000_CA73FECF27A9Eevansyahooinccom_"
MIME-Version: 1.0

--_000_CA73FECF27A9Eevansyahooinccom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

One thing to be aware of is that with -SNAPSHOT at the end of the version M=
aven will start looking at dates.  So if you have a 0.23.0-SNAPSHOT that yo=
u personally modified/built in your .m2 repository and go to build somethin=
g that depends on it.  If the nightly build has pushed it to the apache rep=
o after you built your version maven might download the "newer" version rep=
lacing your changes.  If you changes impact multiple components then your c=
hoices are to always build the entire project (or at least the subset that =
has dependent changes) or always build with -o after your initial build/ins=
tall.

--Bobby

On 8/19/11 11:41 AM, "Matt Foley" <mfoley@hortonworks.com> wrote:

Thanks for the nice clear statement, Alejandro.
--Matt

On Thu, Aug 18, 2011 at 4:40 PM, Alejandro Abdelnur <tucu@cloudera.com>wrot=
e:

> This is handled by maven reactor.
>
> When your run Maven in a multimodule project (like we have), all modules
> that are part of the build (from the dir where you are) down are used for
> the build/test/packaging, all modules that are not part of the build are
> picked up from .m2/repo.
>
> For example
>
> "cd trunk/hadoop-mapreduce;mvn compile" uses hadoop-common & hadoop-hdfs
> from m2/repo
>
> "cd trunk;mvn compile" uses hadoop-common, hadoop-hdfs, hadoop-mapreduce
> from the build.
>
> HTH
>
> Thxs.
>
> Alejandro
>
>
> On Thu, Aug 18, 2011 at 4:35 PM, Matt Foley <mfoley@hortonworks.com>
> wrote:
>
> > Since we put all the effort into "un-splitting" the components, shouldn=
't
> > we
> > have a switch
> > that causes, eg, the MAPREDUCE build to pick up artifacts from COMMON a=
nd
> > HDFS builds
> > in specified sibling directories, without using m2 as an intermediary?
> >
> > Of course it should respect dependencies (via maven) so that if HDFS
> source
> > has been modified,
> > the HDFS artifacts will also be rebuilt before MAPREDUCE uses them :-)
> >
> > --Matt
> >
> > On Thu, Aug 18, 2011 at 3:30 PM, Giridharan Kesavan <
> > gkesavan@hortonworks.com> wrote:
> >
> > > Hello,
> > >
> > > Its the same -Dresolvers=3Dinternal for the ant build system; For the
> > > maven/yarn build system as long as you have the latest common jar in
> > > the m2 cache its going to resolve common from the maven cache. If not
> > > from the apache maven repo. You can force the builds to use the cache
> > > by adding -o option. (offline builds)
> > >
> > > Thanks,
> > > Giri
> > >
> > > On Thu, Aug 18, 2011 at 3:19 PM, Eli Collins <eli@cloudera.com> wrote=
:
> > > > Hey gang,
> > > >
> > > > What's the new equivalent of resolvers=3Dtrue in the new MR build? =
ie
> > > > how do you get a  a local common change to get picked up by mr?
> > > >
> > > > Thanks,
> > > > Eli
> > > >
> > >
> >
>


--_000_CA73FECF27A9Eevansyahooinccom_--