IDEA--maven的使用和maven的生命周期

1、profile

真实项目中，每一个项目都会有多套环境，包括开发环境，测试环境，灰度机环境以及最终的生产环境，每一套环境对应着不同的配置参数，比如JDBC连接信息肯定会有所差别，如果发布到某一环境中就需要改写一次配置文件，只有一个jdbc.properties还可以接受，想象一下真实项目中的配置文件的数量头就大，更重要的是如果写错了某参数后果将不堪设想！此时利用Maven管理的的另一个长处变显现出来了，利用Maven可以为每一个环境配置一个Profile，编译的时候指定Profile的名字即可达到编译文件按需产生。
在pom.xml中配置，标签如下：

2、Lifecycle

====================================
以下引自：http://blog.csdn.net/u010414666/article/details/50060417

概述

日常开发中，我们用到的maven相关功能大概以下几种：
1、 管理jar依赖
2、 构建项目（打包、编译等）
3、 发布项目（共享、上传至服务器，供他人使用）

简单介绍：

1、管理依赖

jar一般在pom.xml文件的中配置，以spring core为例，一般格式如下：

<dependency>
     <groupId>org.springframework</groupId>
     <artifactId>spring-core</artifactId>
     <version>4.1.1.RELEASE</version>
</dependency>
  
  
1
2
3
4
5

其中groupId一般为项目（jar war pom等）的发布机构名称；
artifactId为项目名称；
version为项目版本；
在项目编译打包的时候，ide会自动到maven仓库去查找相应的jar文件，打包并存放在项目的相应路径下（如web项目的lib目录下）
（关于依赖的各个名称和写法，请见后文：详细说明–依赖说明）

2、构建项目：

这里所说的构建项目主要指打包、编译、运行测试用例等操作，即maven的生命周期中的打包过程。
最常用的就是compile了，一般项目修改代码以后都要重新编译，然后加载到tomcat中运行调试。
其它的还有clean、package等比较常用的操作，请见详细说明–生命周期部分

3、发布项目：

如果我们写一些通用框架，或者自己封装了一些常见的工具类，想要打包为jar并且供他人使用，那么我们可以通过maven发布到公共仓库（私服）供他人下载依赖使用。
比如每个公司都会有自己的框架，持久层、控制层或者其它功能等。当我们没有使用maven的时候，我们是直接把别人的jar拷贝到项目的library目录下，而现在我们有了maven就不用自己到处拷贝jar包了，只需要在发布的时候找到别人发布到仓库时候写的groupId artifactId version等信息就能直接添加依赖了，也就是相当于第一步的依赖管理。

4、多模块

maven实际上通过多模块的思想来组织依赖的，每一个项目或者jar都是一个模块，我们可以把一些通用的，不常变动的东西写在一些指定的模块下，在另外一个项目中引用依赖（这里就有点类似【1、依赖管理】，这样一来可以让项目结构更清晰、方便别人依赖使用，如果项目都是一个模板，也可以复用等等，还有其它各种好得自己摸索感受吧）

详细说明：

1、依赖名称：

这里要注意，在我们自己发布项目时尽量遵守以上规范，否则当别人搜索依赖时会写的很冗余很混乱，这也是很多私服中不断重复上传相同jar会导致项目出错的原因。
正常来说，一个项目（如spring的jar）应该是机构、名称和版本唯一的，当我们引用时，可以通过这三个参数唯一标识出一个项目，在上传这些项目的时候，很多人喜欢在artifactId中写上本该属于groupId的内容，这其实是不合理的。
举个错误写法例子：

<dependency>
     <groupId>org.springframework</groupId>
     <artifactId> org.springframework .spring-core</artifactId>
     <version>4.1.1.RELEASE</version>
</dependency>

  
  
1
2
3
4
5
6

这里在artifactId中重复定义了本该属于groupId的内容，所以这样对于项目发布来说是不规范的。

2、依赖在哪：

因为我们安装maven是要配置maven主程序目录、maven配置文件目录、maven仓库目录这三个路径的（可能ide会有自动配置，但这三个都是必不可少的）
maven主程序也就是我们下载的maven插件的根目录；
maven配置文件路径就在maven主程序目录\conf\下，默认名为setting.xml；
maven仓库目录也就是maven自动下载jar所存放的目录以及我们项目发布的本地目录。
当我们编译项目时一般会有如下过程：
1）编译
2）找到pom文件，并扫描相关依赖
3）根据pom中依赖配置信息，到本地maven仓库去查找jar包
4）如果本地没有jar，maven会到它的中心仓库下载jar（
1. http://www.sonatype.org/nexus/
2. http://mvnrepository.com/）
5）如果你公司创建了私服，并且你的maven中做了配置，那么在本地没有找到jar包时，会根据maven的配置文件(conf/setting.xml)所配置的地址，到maven的私服仓库去寻找jar，私服也会根据它的配置规则在本地或中央仓库查找jar，如果本地没有就从服务端下载到本地。（私服的优点见下文）

在步骤1 中，编译会将本地*.java编译为字节码文件，其中很多jar依赖于第三方类库，这时候IDE会根据已配置的 maven\conf\下的setting.xml文件中的配置（或IDE的maven仓库路径）去查找相应jar包。如果有jar包，则会拷贝到项目的编译目录下（myEclipse默认为“tomcat\webapp\lib\”目录下；Intellij IDEA 默认在“项目target\webapps\lib”目录下）,
如果本地没有，那么会先去仓库下载到本地，再从本地拷贝到项目编译目录。
其它的下载过程最终也会下载到本地并拷贝到编译目录，更多详情就不多解释了，可自行学习。

3、生命周期：

maven将项目的生命周期大致分为9个，分别为：clean、validate、compile、test、package、verify、install、site、deploy
我经常用的也就是clean、compile、package、install、deploy，而且deploy相对也较少，因为很少发布公共的项目供别人依赖使用，基本也就是项目打包为war时候会打包到私服，运维人员可以到私服上直接下载对应版本。
其中clean即清除项目中编译文件和本地仓库中已打包的文件（即本地install的文件，install后面讲到）
compile即编译项目中的java文件，并存放在项目的编译目录（根据不同的配置，编译目录也不一样）
test 即运行项目中的测试用例文件，如果测试用例未通过，也会打包失败，另，这里的test过程可以在pom中通过配置跳过。（想想也是，我项目都好了，其实不是非要跑测试用例的）
package 即将本地编译好的文件打包为war 或者jar(这是最常见的两种，其他相关自行了解)
verify 我很少用到，没怎么了解过
install 将打包的代码存放到本地maven仓库，可供本地其它项目依赖使用
site生成项目报告，站点，发布站点，这个也很少用到，不是很清楚
deploy 将打包在本地仓库中的项目发不到服务器，供他人依赖使用
详细生命周期自行学习了解。

4、私服的优点

在上述过程中，私服的作用相当于本地的maven仓库，但它同时又作为服务器的角色来为局域网用户提供jar下载，在很多开发环境中，开发机器是不允许连接互联网的，所以这时候maven就不能正常访问中央仓库下载jar文件，所以这里的私服仓库就显得尤为重要了。私服所在服务器提供了同时访问内网和互联网的功能，当用户找不到jar包依赖时，可以通过内网访问私服服务器，如果私服没有，那么私服会通过互联网去中央仓库或其它仓库下载，这样可以一定程度上保证开发环境的安全性。
另一方面局域网的访问速度普遍是比互联网快的，如果在本地没有jar，当局域网用户下载jar包且私服没有时，私服的带宽比较大便可以更快速的下载到jar并回传到开发者本地，这样可以保证在复杂的网络环境或网络不通畅的时候依然可以使用maven相关的功能。并且，当局域网中有用户下载了相应jar包后，其它用户再次需要该jar包时私服仓库便可以直接从私服服务器本地直接通过局域网发送给局域网用户，这样大大减少了带宽、流量并解决了很多由于网络环境导致的问题。

注

由于平时接触的jar war比较多，文中很多地方对依赖或者项目打包都简单以jar来说明，其实那些jar不单是指jar包文件，还可以是war、pom、或者项目目录结构打包的相关类型的文件，为了便于理解暂用jar来说明，待知识体系再完善还会进一步修改哈。I’ll be back -3-