134 lines
5.1 KiB
Bash
134 lines
5.1 KiB
Bash
#!/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 hbase-0.95.2-SNAPSHOT hbase-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
|