提交 7b40c876 编写于 作者: R Robert Metzger

Travis support for new profiles, readme, comments in script

上级 c2fcda6d
......@@ -4,9 +4,9 @@ jdk:
- openjdk7
- openjdk6
env:
- PROFILE=hadoop_v1
- PROFILE=hadoop_yarn
- PROFILE=
- PROFILE="-Dhadoop.profile=2"
install: true
script: "mvn -P$PROFILE clean verify"
script: "mvn $PROFILE clean verify"
......@@ -35,7 +35,33 @@ If you’re a Debian/Ubuntu user, you’ll find a .deb package. We will continue
cd stratosphere-dist/target/stratosphere-dist-0.2-ozone-bin/stratosphere-0.2-ozone/
Note: The directory structure here looks like the contents of the official release distribution.
The directory structure here looks like the contents of the official release distribution.
#### Build for different Hadoop Versions
This section is for advanced users that want to build Stratosphere for a different Hadoop version, for example for Hadoop Yarn support.
We use the profile activation via properties (-D).
##### Build hadoop v1 (default)
Build the default (currently hadoop 1.2.1)
```mvn clean package```
Build for a specific hadoop v1 version
```mvn -Dhadoop-one.version=1.1.2 clean package```
##### Build hadoop v2 (yarn)
Build the yarn using the default version defined in the pom
```mvn -Dhadoop.profile=2 clean package```
Build for a specific hadoop v1 version
```mvn -Dhadoop.profile=2 -Dhadoop-two.version=2.1.0-beta clean package```
It is necessary to generate separate POMs if you want to deploy to your local repository (`mvn install`) or somewhere else.
We have a script in `/tools` that generates POMs for the profiles. Use
```mvn -f pom.hadoop2.xml clean install -DskipTests```
to put a POM file with the right dependencies into your local repository.
### Run your first program
......
......@@ -57,17 +57,15 @@ nupom="pom.${hadoop_version}.xml"
poms=`find $ozone_home -name pom.xml`
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.
# 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.hadoop1.xml or pom.hadoop2.xml). 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/${old_ozone_version}/${new_ozone_version}/" \
-e "s/\(<module>[^<]*\)/\1\/${nupom}/" \
-e "s/\(relativePath>\.\.\)/\1\/${nupom}/" \
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册