之所以要使用maven去编译hadoop源码，还是hadoop的native给闹的，最新版本的native都是64位的，奈何小编的操作系统是32位的，虽然使用64位的native也能运行，但是看着每次执行命令那一大堆的警告很不舒心，于是乎下决心要解决这个问题，maven编译hadoop源码就应运而生，虽然在操作之前看到各方评论已经知道这不是个简单的事情，但是真正操作之后才知道，何止不简单，简直是极其痛苦，不过总算是熬过来了，下面就maven编译hadoop源码的一些心得体会写出来供大家参考。
测试环境：虚拟机，单核CPU，1G内存，centos 6.5 32bit，hadoop 2.6.2。
首先下载hadoop2.6.2的源码，我们直接到hadoop的官网进行下载，然后解压缩。
然后就是安装maven，本来想着使用yum安装，但是yum了下，居然没有，本想着放弃采用源码安装，没想到居然让小编查到了一种可以采用yum安装maven的方法，迫不及待的去尝试了下，没想到十分成功，各种依赖组件也随之安装，跟平时使用yum没什么两样。
wget http://repos.fedorapeople.org/repos/dchen/apache-maven/epel-apache-maven.repo -O /etc/yum.repos.d/epel-apache-maven.repo我们可以通过mvn --version来测试下maven是否安装成功。
yum install apache-maven
接着我们进入解压过的hadoop源码包，然后执行下面的命令，这个命令在安装过程中会多次执行，因为第一遍基本不可能成功，关于hadoop的native库相关更详细的信息点击此处。
mvn package -Pdist,native -DskipTests -Dtar
准备工作完成后，接着就是痛苦的尝试了，为了更加真实的还原生成hadoop的native库的艰难历程，这次小编使用了最干净的环境（初装centos，没有进行过其他任何软件和组件的安装），痛苦的旅程即将开始，小伙伴们期待吧。
尝试前的温馨提示：
1.JAVA_HOME环境变量是必须设置，否则还没开始就结束了。
2.jdk不要使用yum的openjdk，要官网下载版的oracle版的jdk，否则会出现让你找不着北的问题。
3.jdk的版本不要1.8的，要1.7的，否则会出现各种问题。
4.设置MAVEN_OPTS=-Xmx512m，否则会出现java.lang.OutOfMemoryError: Java heap space，java虚拟机内存溢出问题。
5.如果条件允许的话，操作系统的内存尽量保持在1G以上，否则编译的时候会非常卡。
之所以再开篇前剧透，是因为遇到有些问题的时候，虽然是上述原因产生的，但是却没有任何迹象表明，未知的才是最恐惧的，为了减轻小伙伴的痛苦，尝试前先做下准备工作吧。
在mvn过程中可能会中断很多次，但并非每次都是遇到了错误，有时候可能是因为网速不好导致，是否是遇到错误，可以多次执行mvn进行判断，如果超过两次都在同一个位置中断的话，证明可能遇到了问题，此时我们就需要根据错误提示来找出问题，并解决它。
即使没有坑，完整安装一次也会耗时半小时左右，何况坑这么多，一个一个填完可能会耗时很久，如果不想耗费这么多时间，可以提前看看有多少坑，能填的先填填，这样安装过程将会最小化。
问题一：刚执行mvn就报错，一个文件都没有成功被Download。
刚上来就遇到问题是不是着实不爽，小编亦是如此，尤其是当看到一大堆看不懂也百度不出来的东西，输入了上述各种关键字，也没找到一个解决的办法，经过各种尝试，偶然间发现问题已经解决，但是由于尝试了很多方法，不知道添加了什么使得这个问题得到了解决，于是乎抽丝剥茧，终于发现该问题的解决之道，关键就在于JAVA_HOME。其实在yum安装maven的时候，java作为依赖就已经被安装成功，而且测试mvn -version的时候也输出了Java home等相关信息，于是就没有再往JAVA环境上面想，认为yum安装的时候应该设置过JAVA_HOME，否则mvn -version的时候怎么会没报错，但当阅读过大量的教程之后，发现很多教程都手动设置了JAVA_HOME，于是乎对于maven是否真的成功找到JAVA环境产生了质疑，抱着尝试的态度，设置了JAVA_HOME，没想到居然成功的解决了这个问题，难道真的是mvn在进行操作的时候找不到对应的JAVA环境所致？看来应该是了，这次给小编提了个醒，以后凡是依赖JAVA执行的程序，首先看看JAVA环境是否设置了。
小知识
设置JAVA_HOME的三种方法
export JAVA_HOME="具体的JDK路径"1.单一终端型：直接在终端中输入上述命令，这种方法设置的环境变量只能在当前终端使用（切换用户同样可以使用该环境变量）
2.单一用户型：在用户的家目录下，有一个名为.bashrc配置文件，在该文件中添加上述命令，然后使用source .bashrc（参考注意事项）命令使该配置文件生效，该方法设置的环境变量只能在该用户所在的环境下使用，切换用户之后该环境变量不生效。
3.全部用户型：在/etc/profile中添加上述命令，然后使用source /etc/profile（参考注意事项）使之生效，该方法设置的环境变量可以为全部用户提供服务。
如果使用yum安装的JAVA，JDK的安装目录一般在/usr/lib/jvm中。
注意事项
在测试的过程中，我们经常需要调整配置文件，为了使配置文件及时生效，我们通常使用source 命令。但是使用source的时候需要注意，首先不同用户之间的source的结果不能互用，例如root下执行过source /etc/profile，如果退出了root用户，那么普通用户则不能享受到root用户source之后的结果。同一用户，不同终端的source结果也不能互用，例如用户A在终端1下使用了source，再新打开一个终端2，则终端2不能享受到终端1的source结果。总之一句话，source处处是陷阱，为了不踩陷阱，还是麻烦点，每次更改完配置后都重启下吧。
问题二：SSL peer shut down incorrectly
这个问题算是小编遇到的最多的一个问题了，其实这种情况根本不算是什么问题，至于为什么经常出现，是因为小编的网速比较渣，每次一个文件下载不成功的时候就会出现这个问题，之所以首次安装的时候折腾了几天，网速渣也是直接原因之一，如果你的网速很好，或许不会遇到这个问题，如果你也遇到了这个问题，不要惊慌，再次执行mvn命令即可，让它重新去下载该文件。