搭建Nexus私服。
首先去官网下载window下用的zip文件。https://www.sonatype.com/download-oss-sonatype。
解压之后包含下面两个文件
进入nexus下面的bin目录
在cmd命令下，执行nexus.exe /run，就可以启动成功了。
另外nexus.vmoptions是nexus的配置文件里面可以修改数据的存储路径。
我这里把路径修改为nexus-data.
重启nexus，然后目录下就多出了一个nexus-data文件，并且和之前解压出来的sonatype-work是一样的，可见之前的sonatype-work文件就是用来存储nexus数据的。
nexus-3.1.0-04\etc目录下的nexus-default.properties文件是用来配置。修改IP、端口、访问根目录的。配置成你想要的数据之后
再启动nexus，然后就可以访问http://127.0.0.1:8091/nexus-console/
安装成功后默认账户是admin具有全部权限默认密码admin123
登录之后我们就可以配置我们的仓库。
其中central库的类型是proxy，里面的URL是maven*存储库，http://repo1.maven.org/maven2/。
Public 库的类型是group。这说明public库是一个组，而组里面是可以把你需要的库给配置进去。
而release库和snapshots库，都是host类型的，也就是我们自定义库。其中release库放的是稳定版本的jar，snapshots库是放置快照版本的jar。稍后我们会解释release和snapshots之间的区别。
下面我们配置一个自己本地库，用来放置一些我们自己第三方jar包，实际上大部分的jar包都是可以在公共库里面找到的，所以我就自己随便找一个jar为例子。
下面我们先创建一个host类型的库，作为我们本地库。
然后输入你想要的名字就行了，其他的配置基本不需要改变。
配置完成后，列表里面就会把你的那个库给显示出来。
下面我们尝试向这个第三方库里面上传jar包。我们要把D盘下面的ojdbc-6.jar给上传到我们的maven thirdParty库里面
Nexus2系列里面是可以在图形用户界面直接上传jar的，但是在nexus3里面，我并没有找到怎么上传，网上也没有，所以我们姑且用命令上传吧。
首先在你的maven配置文件里面，\conf\settings.xml里面配置服务器的信息
然后cmd执行如下命令，别直接拷贝因为为了方便阅读我给换行了。Cm窗口下你要写成一行。
mvn deploy:deploy-file
-DgroupId=com.test
-DartifactId=ojdbc
-Dversion=6
-Dpackaging=jar
-Dfile=D:\ojdbc-6.jar
-Durl=http://127.0.0.1:8091/nexus-console/repository/maven-thirdParty/
-DrepositoryId=nexus
这里面url一定要注意，ip和端口就不再解释了，nexus-console必须和你在nexus-3.1.0-04\etc目录下的nexus-default.properties这个文件里面配置的nexus-context-path对应，repository是固定的，nexus3里面就用这个，而nexus2里面用的是content\repositoris，maven-thirdPary是你的库的名字，另外后面的/也是必不可少的。
上传之后我们就可以在自己nexus私服看到了。
---------------------------------------------------------------------
下面我们开始尝试把刚才上传的那个jar包，做为第三方库给拉下来。
我用的IDE是IDEA15，里面的maven需要在settting里面配置一下，eclipse相应的也需要配置一下。
既然我们需要去服务器上把我们的jar包给拉下来，那么肯定是要把jar包对应的路径给maven指示出来。
这里有两种方式
第一种是配置在Pom 文件里面，放在project节点下面就好了。
配置在setting.xml里面，这样的话就使用该maven的所有项目。需要放在profile下面
为了让着profile有效我们还需要配置。（这个配置，如果你只有一个repository的话，activeProfiles应该是可以不配置的，我测试过，没有这个配置仍然有效。）
目前这种情况下，如果我们私服上找不到还是回去*库找的。那我们如何让maven只在本地库找呢？
这就需要在setting.xml里面配置mirrors，然后再repository里面把id配置为central，这样id为central的配置会覆盖maven的base pom的默认配置。这时候profile配置的url其实已经没有什么意义了，配置仓库和插件仓库的主要目的是，控制release和snapshot版本是否可用。当maven需要下载构件的时候，会先去访问central的配置，查看是否支持下载快照或者是release版本。当得到肯定的回复的时候，就会走mirrors的配置，所以仓库自己的路径其实已经没什么用，配置成什么都可以。
我们现在尝试下是否能下载下来。
用IDEA新建一个common的maven项目，就叫common，pom文件添加如下配置。
然后maven自动就会把该jar包下载到本地。另外需要注意的是，对于maven2，和3，modelVersion都是4.0.0
然后我们可以对common项目打包，默认是打包为jar。
运行mvn clean package,目的是把代码打包到package。我们可以直接运行在项目目录下运行
Mvn clean package，这行命令的意思就是把该项目打包，根据pom文件里面的packaging字段的类型来打包，我们先打包成jar（不配置默认就是打包成jar）。
这样的话，我们的jar包就被打包到target目录下了，而这时候我们的本地库还是没有的，那么假设我们还有别的maven项目要依赖这个jar包，还是找不到的，这时候，我们就需要运行mvn clean install。
这样的话，我们的本地库就是有这个，那别的项目配置上依赖，就可以引用这个jar包了。找个稍后演示。
下面我大致解释下，maven命令的生命周期。
首先大家看下，我执行mvn clean install时候的控制台。
从截图我们可以看出，maven的命令，其实就是执行某个插件的某个方法，比如
Clean命令就是执行了clean插件下的clean方法，效果是删除了target目录下所有的文件。
但是我们明明没有执行过compile命令，为什么也调用到了compile:compile方法呢？这就是跟maven的生命周期有关了。
生命周期其实是一个抽象出来的概念，我们在一个项目中，经常需要进行，编译，测试，打包，部署，等等一系列的动作。比如有时候我们需要打包，那么我们至少要先进行编译吧，maven就把这些动作抽象为不同的生命周期，在每一个生命周期里面，都定义好了步骤（相当于一个抽象类），而插件就是用来实现具体逻辑的，就是实现这个抽象类。这样就可以方便的通过配置插件来实现构建的行为，甚至可以自己书写插件来实现某些特殊的需求。
Maven是有3套独立的生命周期的生命周期。
Clean生命周期的目标是清理项目，包含：
1 Pre-clean
2 Clean
3 Post-clean
Default 生命周期，是构建的核心阶段，包括
- validate
- initialize
- generate-sources
- process-source
- generate-resource
- process-resource
- compile
- process-class
- generate-test-sources
- process-test-sources
- generate-test-resources
- process-test-resources
- test-compile
- process-test-classes
- test
- prepare-package
- package
- pre-integration-test
- integration-test
- post-integration-test
- verify
- install
- deploy
site 生命周期，主要是建立站点和发布的。
- pre-site
- site
- post-site
- site-deploy
这三个生命周期是独立的，互不影响的，而生命周期本身是从上到下的。
比如，你只执行clean命令，那么实际执行的是pre-clean 和 clean两个动作。
你执行compile命令，执行的是Default 1~7所有的动作。
而只执行compile的话，是不会触发clean相关的动作的。
这也就解释了为什么我们一条命令会有那些动作的原因了。
下面说下，聚合跟继承。
首先说聚合，当我们项目中有多个子项目，并且这些子项目又需要同时构建的话，那我们就需要在每一个目录下面执行mvn install命令。
这样工作就比较重复，我们可以通过聚合来实现只执行一条命令，就同时构建多个项目。
然后再说继承。
就和java一样，如果有两个很相似的类，里面又有大量相同的代码，那我们会把相同的部分抽出来成为一个父类一样。Maven也可以有这种结构，这样就可省却大量的配置。
首先我们新建一个maven项目pom_base，由于这是一个用来被继承的maven项目，所以并不需要有什么代码，只需要一个pom文件
然后我们在common的pom里面继承parent。注意，packaging一定要是pom类型的
这时候可以看到，pom是有报错的，报错如下：
报错原因是，common在本地库并没有找到我们pom_base项目的pom文件。这时候我们有两个解决方案。
- 根据报错可以看出来，我们只需要配置<relativePath></ relativePath>标签，指明parent的具体位置就好。
- 把pom_base给install到本地库就好。（我们系统就是采用这种方式）。
我们项目其实很多子项目都继承pom_base.
另外这里面再解释一个标签，以pom_base为例子。就是定义变量，比如对于spring很多依赖版本是一样的，那么就可以把这些版本抽出来成为一个变量，这样的话，改起来的话只需要改这个变量的值就好了。
然后我们新建第三个项目，springStudy(名字忽略)
然后依赖common，继承pom_base.
这样我们就基本模拟了现在的项目结构。
比如，vst_front会依赖vst_common同时再继承vst_pom_base.
最后再说一下怎么样发布到我们nexu私服上。为了发布到服务器上，首先要在pom配置
然后在setting.xml配置server信息，因为默认的访问权限是只读的，你是不能发布到到nexus上的，所以要配上管理员权限的server(前文有说过怎么配置)。我们可以把上面的配置在pom_base里面，这样我们的三个项目就都可以放到nexus上了，不需要每个pom都配置一遍。
为了都尝试下，我comm放的是snapshot版本，springStudy放的是release版本
然后执行mvn deploy，遗憾的是报错了，没有被授权，这是因为我之前配置server的时候只配置了一个server，id是nexus
所以我把id改为nexus就好了
这样就上传上去了
最后再解释下 snapshot和release的区别。本身就理解的请忽略。
举个例子，如果A,B两人协作, A开发common，B开发springStudy。A开发完common，如果B需要用A新开发的代码，那么假设，A传到nexus上的版本是1.0，那么就算他的代码改动了B那边也不会把这个新的1.0给下载到本地库的，因为对于B来说他认为新上传的1.0和以前的1.0没区别。这时候为了告诉B两个是不一样的，A需要把pom版本改为2.0然后再deploy，假设频繁修改代码，就需要频繁的改动pom文件。而SPANPSHOT版本可以解决这个问题，这时候A只需要把pom文件里面的版本改为1.0-SNAPSHOT这时候当他deploy到nexus上的时候，jar包后面会自动跟上一个时间戳，如下面的例子一样。这时候B那边就知道它本地库的和nexus上的是不一样的，可以去nexus上把最新的版本更新下来了。