打包还在用jar，阿里技术专家教你用Maven打包发布上线项目
Maven在日常应该是用得挺多的，毕竟我们都需要打包发布上线的嘛，但是刚毕业的时候可没有这个概念。
我们肯定是知道Maven能管理我们的项目，但是在学习的时候往往只用到Maven来导入各种的依赖。
我们肯定是知道Maven是有对应的仓库，然后我们配置了国内的Maven仓库来让jar包下载得更快。
我们可能会用Maven来编译自己的项目，本地打好package，然后将项目在本地启动起来。如果我们有一台机器的服务器，打完包以后就将本地的war包手动上传到自己的服务器上启动。
我们可能会知道Maven可以配置自己的仓库（私有仓库），可能会搭建过，但是又有哪几个人将自己的jar包发布到私有的仓库呢？
去到公司里边，公司一般也有自己的私有仓库，我们写的系统可能会被各个团队使用的，所以我们会把写好的包打到私有仓库上。常用到的Maven命令其实不会很多，一般就是以下的几个：
1、mvn compile
2、mvn test
3、mvn clean
4、mvn pakage
5、mvn install
6、mvn deploy
7、mvn versions:set -DnewVersion=xxxx 设置Maven的版本
8、mvn dependency:tree 查看maven的依赖树（排查依赖很有效）
常用参数
-Dmaven.test.skip=true
-Dmaven.JAVAdoc.skip=true
直接从网上摘录以下package、install、deploy的区别：
- package命令完成了项目编译、单元测试、打包功能，但没有把打好的可执行jar包（war包或其它形式的包）部署到本地maven仓库和远程maven私服仓库
- install命令完成了项目编译、单元测试、打包功能，同时把打好的可执行jar包（war包或其它形式的包）布署到本地maven仓库，但没有布署到远程maven私服仓库
- deploy命令完成了项目编译、单元测试、打包功能，同时把打好的可执行jar包（war包或其它形式的包）部署到本地maven仓库和远程maven私服仓库
一个工程下一般也会有多个Module，我们会用父工程的pom.xml来管理我们的jar包版本，在子Module引用父工程的就好了。
别傻乎乎地就将各种jar包的版本到子Module下写，虽然jar包是肯定能导入进去了，但是这样做不规范。
下面简单体验几个最常用的命令（建议自己实操一下）
mvn compile -Dmaven.test.skip=true，这个命令会把我们的代码编译，编译完我们如果使用IDEA就可以发现有target目录
mvn package -Dmaven.test.skip=true就可以帮我们打包。
三歪一次不可描述的经历
最近三歪在整合系统，把一些零散的系统整合到一个系统里边，所以一个系统会出现多个Module。之前项目也是多个Module的，只是没有现在的多，比如下面的图
从上面的图我们可以看到在父工程下有几个配置文件，分别是dev/local/online/pre。很明显地，我们不同的环境下，配置应该是不一样的。
这应该很好理解，我们线上的服务器配置信息和测试环境的配置信息怎么可能相同嘛，所以各个环境的配置是分开的。
因为要做合并的事，我就把一些系统合并到父工程里边去。所以我会在父工程下新建Module，然后把代码拷贝进去。显然，每个工程可能都会有相应的配置，然后配置也是区分环境的嘛。
比如下面的图（sanwai.name这份配置由各个环境下的配置所去读取）：
我在各个环境下的配置文件都写好了sanwai.name的值了
等我一切写完的时候，我发现服务一直启动不起来，始终没有读到我在dev/local/pre/online配置的值。我就很怀疑了，明明我配置了呀。
Spring的property-placeholder我明明都已经写好了，路径都没有任何问题，在本地都能直接「点」去跳转到对应的配置文件了。这咋回事啊
<context:property-placeholder
ignore-unresolvable="true" ignore-resource-not-found="true"
location="classpath*:core-config.properties" />
于是，我花了很长的一段时间上看我的property-placeholder是不是有问题，是不是我哪里的使用姿势不对。
最后实在忍不住了，问了一下同事有没有遇到过这个坑，然后同事告诉我：分环境读取配置不是Spring的功能，是Maven
我：？？？？然后在内网搜了一下，还真的是。大概看了一下，其实就是用到了Maven的profile功能。
后来在pom文件下指定读取对应的配置文件路径，就可以了。
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering><!-- 是否使用过滤器 -->
</resource>
</resources>
</build>
其实就是在打包的时候去指定不同的环境，从而生成一份正确的配置文件。
mvn clean package -DskipTests -Ptest // 指定的是test环境
那么按道理，只要我发布上线过代码，就应该知道有这么一个东西啊。
我司有自己的一套发布系统，把很多的细节都给屏蔽掉了（无论是Git还是Maven的细节都屏蔽了很多）。压根就不需要自己去打命令去创建Git分支，去合并master分支，去敲maven的命令打包。
最后在这里推荐一本Maven实战文档
本书适合所有Java程序员阅读。由于自动化构建，依赖管理等问题并不只存在于Java世界，因此非Java 程序员也能够从该书中获益。无论你是从未接触过Maven、还是已经用了Meven很长时间，亦或者想要扩展Maven,都能从本书获得有价值的参考建议。
其次，本书也适合项目经理阅读，它能帮助你更规范、更高效地管理Java项目。
第1章对Maven做了简要介绍，通过-些程序员熟悉的例子介绍了Maven 是什么，为.什么需要Maven.建议所有读者都阅读以获得一个大局的印象。
第2-3章是对Maven的一个人门介绍，这些内容对初学者很有帮助，如果你已经比较熟悉Maven,可以跳过。
第4章介绍了本书使用的背景案例，后面的很多章节都会基于该案例展开，因此建议读者至少简单浏览一遍。
第5-8章深人阐述了Maven 的核心概念，包括坐标，依赖、仓库。生命周期、插件，继承和多模块聚合，等等，每个知识点都有实际的案例相佐，建议读者仔细阅读。
第9章介绍使用Nexus建立私服，如果你要在实际工.作中使用Maven,这是必不可少的。
第10-16章介绍了一些相对高级且离散的知识点,包括测试，持续集成与Hudon, Web项目与自动化部署、自动化版本管理、智能适应环境差异的灵活构建、站点生成，以及Maven的Eelipse插件m2elipe,等等。读者可以根据自己实际需要和兴趣选择性地阅读。
第17-18章介绍了如何编写Archeype和Maven插件。一般的Maven用户在实际工作中往往不需要接触这些知识，如果你需要编写插件扩展Maven,或者需要编写Archetype维护自己的项目骨架以方便团队开发，那么可以仔细阅读这两章的内容。
