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 <[email protected]> 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 <[email protected]> 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/ >
