#!/bin/bash
##
# Licensed to the Apache Software Foundation (ASF) under one
# or more contributor license agreements.  See the NOTICE file
# distributed with this work for additional information
# regarding copyright ownership.  The ASF licenses this file
# to you under the Apache License, Version 2.0 (the
# "License"); you may not use this file except in compliance
# with the License.  You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
##

# Generates a pom.xml with a haoop1 or a hadoop2 suffix which can
# then be used for generating hadoop1 or hadoop2 suitable hbase's
# fit for publishing to a maven repository. Use these poms also
# making tarballs to release.  The original pom.xml is untouched.
#
# This script exists because we cannot figure how to publish
# into the local (or remote) repositories artifacts that can be
# used by downstream projects (with poms describing necessary
# includes).  See HBASE-8224 and HBASE-8488 for background.
#
# Generation is done by replacing values in original pom and
# enabling appropriate profile using the '!' trick in the
# hbase.profile property (this is fragile!) so no need to specify
# profile on the command line.  The original pom.xml should be
# what we maintain adding in new depdencies, etc., as needed.
# This script should make it through most any change to the
# original.
#
# Here is how you would build an hbase against hadoop2 and publish
# the artifacts to your local repo:
#
# First run this script passing in current project version and what
# version you would like the generated artifacts to have.  Include
# either -hadoop1 if built against hadoop1 or -hadoop2 if build against
# hadoop2.  These substrings are expected as part of the new version.
#
#  $ bash -x ./dev-support/generate-hadoopX-poms.sh 0.95.2-SNAPSHOT 0.95.2-hadoop2-SNAPSHOT
#
# This will generate new poms beside current pom.xml made from the
# origin pom.xml but with a hadoop1 or hadoop2 suffix dependent on
# what you passed for a new version.  Now build passing generated
# pom name as the pom mvn should use.  For example, say we were building
# hbase against hadoop2:
#
#$ mvn clean install -DskipTests -f pom.xml.hadoop2
#

# TODO: Generate new poms into target dirs so doesn't pollute src tree.
# It is a little awkward to do since parent pom needs to be able to find
# the child modules and the child modules need to be able to get to the
# parent.

function usage {
  echo "Usage: $0 CURRENT_VERSION NEW_VERSION"
  echo "For example, $0 0.95.2-SNAPSHOT 0.95.2-hadoop1-SNAPSHOT"
  echo "Presumes VERSION has hadoop1 or hadoop2 in it."
  exit 1
}

if [[ "$#" -ne 2 ]]; then usage; fi
old_hbase_version="$1"
new_hbase_version="$2"
# Get hadoop version from the new hbase version
hadoop_version=`echo "$new_hbase_version" | sed -n 's/.*-\(hadoop[12]\)-.*/\1/p'`
if [[ -z $hadoop_version ]]; then usage ; fi

# Get dir to operate in
hbase_home="${HBASE_HOME}"
if [[ -z "$hbase_home" ]]; then
  here="`dirname \"$0\"`"              # relative
  here="`( cd \"$here\" && pwd )`"  # absolutized and normalized
  if [ -z "$here" ] ; then
    # error; for some reason, the path is not accessible
    # to the script (e.g. permissions re-evaled after suid)
    exit 1  # fail
  fi
  hbase_home="`dirname \"$here\"`"
fi

# Now figure which profile to activate.
h1=
h2=
default='<name>!hadoop.profile<\/name>'
notdefault='<name>hadoop.profile<\/name>'
case "${hadoop_version}" in
  hadoop1)
    h1="${default}"
    h2="${notdefault}<value>2.0<\/value>"
    ;;
  hadoop2)
    h1="${notdefault}<value>1.1<\/value>"
    h2="${default}"
    ;;
 *) echo "Unknown ${hadoop_version}"
    usage
    ;;
esac

pom=pom.xml
nupom="$pom.$hadoop_version"
poms=`find $hbase_home -name ${pom}`
for p in $poms; do
  nuname="`dirname $p`/${nupom}"
  # Now we do search and replace of explicit strings.  The best
  # way of seeing what the below does is by doing a diff between
  # the original pom and the generated pom (pom.xml.hadoop1 or
  # pom.xml.hadoop2). We replace the compat.module variable with
  # either hbase-hadoop1-compat or hbase-hadoop2-compat, we
  # replace the version string in all poms, we change modules
  # to include reference to the non-standard pom name, we
  # adjust relative paths so child modules can find the parent pom,
  # and we enable/disable hadoop 1 and hadoop 2 profiles as
  # appropriate removing a comment string too.  We output the
  # new pom beside the original.
  sed -e "s/\${compat.module}/hbase-${hadoop_version}-compat/" \
    -e "s/${old_hbase_version}/${new_hbase_version}/" \
    -e "s/\(<module>[^<]*\)/\1\/${nupom}/" \
    -e "s/\(relativePath>\.\.\)/\1\/${nupom}/" \
    -e "s/<!--h1-->.*name>.*/${h1}/" \
    -e "s/<!--h2-->.*<name>.*/${h2}/" \
    -e '/--Below formatting for .*poms\.sh--/d' \
    -e 's/\(<pomFileName>\)[^<]*/\1${nupom}/' \
  $p > "$nuname"
done