Another option is to, keep everything in trunk, and conditionally add
source directory based on version specific code:
As an example of how to include specific directories containing, version
specific code, it is present here:
http://stackoverflow.com/questions/6025596/conditional-exclusion-of-file-from-compilation-in-maven-project
.
Instead of branching , the latest code is still in trunk, but the 'shim'
for specific hadoop version is in a specific directory , say
src/main/hadoop23 and
src/main/hadoop1x
The latest code at any given time is still in the trunk, but based on the
profile-id, the appropriate directories can be added.
--
Karthik.
On Fri, Feb 10, 2012 at 12:38 PM, Brock Noland <brock@cloudera.com> wrote:
> Any thoughts on better ways to do this? If I don't hear anything, I
> will assume this is the easiest way to publish two artifacts.
>
> We could change our release process to do the following:
>
> Create a branch mrunit-X.Y.Z
> Copy the branch to mrunit-hadoop-1.0-X.Y.Z
> Change the pom version to mrunit-hadoop-1.0-X.Y.Z
> Compile mrunit-X.Y.Z against 0.23 or newer
> Compile mrunit-hadoop-1.0-X.Y.Z against hadoop 1.X or newer
> Package and deploy to maven both versions
>
> Brock
>
> On Tue, Feb 7, 2012 at 4:48 AM, Brock Noland <brock@cloudera.com> wrote:
> > Hi,
> >
> > I am interested in your thoughts on:
> > https://issues.apache.org/jira/browse/MRUNIT-56 Basically, while the
> > source code we distribute works with 1.0 and 0.22/0.23, different bits
> > need to be built for the two versions. This is due to some class ->
> > interface changes. Users can do this themselves with the source but
> > since we distribute a jar, it would be handy to provide versions for
> > both 1.0 and 0.22/0.23.
> >
> > I figured out a way to do this, but I am guessing it's largely
> suboptimal.
> >
> > Cheers!
> > Brock
> >
> > --
> > Apache MRUnit - Unit testing MapReduce -
> http://incubator.apache.org/mrunit/
>
>
>
> --
> Apache MRUnit - Unit testing MapReduce -
> http://incubator.apache.org/mrunit/
>
|