maven学习系列--maven的使用

1.maven安装配置

安装环境(windows): 确保已经安装和正确配置了jdk.

1.1 添加    MAVEN_HOME  环境变量到 windows 环境变量,并将其指向你的 maven 的文件夹
1.2 添加   %MAVEN_HOME%\bin;   到 path 变量,这样就可以在命令中的任何目录下运行maven命令,
1.3 执行  cmd (开始-->运行-->cmd) mvn -version  显示如图既安装成功,

2.maven启动代理访问

如果你的公司正在建立一个防火墙，并使用HTTP代理服务器来阻止用户直接连接到互联网。如果您使用代理，Maven将无法下载任何依赖。为了使它工作，你必须声明在 Maven 的配置文件中设置代理服务器：settings.xml.

2.1  找到文件 (你的maven地址)/conf/settings.xml, 并把你的代理服务器信息配置写入,取消注释代理选项，填写您的代理服务器的详细信息。

<!-- proxies
   | This is a list of proxies which can be used on this machine to connect to the network.
   | Unless otherwise specified (by system property or command-line switch), the first proxy
   | specification in this list marked as active will be used.
   |-->
  <proxies>
      <proxy>
      <id>optional</id>
      <active>true</active>
      <protocol>http</protocol>
      <username>hou</username>  <--- 需要配置的代理服务器的username
      <password>password</password>  
      <host>proxy.hou.com</host>  <--- 需要配置的代理服务器的 
      <port>8888</port>  <--- 需要配置的代理服务器的port
      <nonProxyHosts>local.net|some.host.com</nonProxyHosts>
    </proxy>
  </proxies>

2.2 完成后,maven应该是能够通过代理服务器立即连接到Internet(不需要重启maven)

3.maven本地资源

3.1 Maven的本地资源库是用来存储所有项目的依赖关系(插件jar和其他文件，这些文件被Maven下载)到本地文件夹, Maven的本地资源库默认为 .m2 目录文件夹C:\Documents and Settings\{your-username}\.m2

3.2 更新maven本地库地址, 通常情况下可以改变默认的.m2目录下的默认本地库到其他地址.  找到(你的maven地址)/conf/settings.xml, 更改 localRepository 到其他地址.

<settings><!-- localRepository
   | The path to the local repository maven will use to store artifacts.
   |
   | Default: ~/.m2/repository
  <localRepository>/path/to/local/repo</localRepository>
  --><localRepository>D:\maven\apache-maven\repository</localRepository>  <--- 在这里更改要替换的其他目录地址

3.3 更改保存之后新的maven本地存储库已经改为 D:\maven\apache-maven\repository (当然 D:\maven\apache-maven\repository 这个路径要存在对应文件夹才可以.)

4.maven 中央存储库

当你建立一个 Maven 的项目，Maven 会检查你的 pom.xml 文件，以确定下载哪些依赖。首先，Maven 将从本地资源库获得 Maven 的本地资源库依赖资源，如果没有找到，会从默认的 Maven 中央存储库 – http://repo1.maven.org/maven2/ 查找下载.

5.maven远程资源库

5.1 在Maven中，当你声明的库不存在于本地存储库中，也没有存在于Maven中心储存库，将停止下载并将错误消息输出到 Maven 控制台。

Downloading in Maven is triggered by a project declaring a dependency that is not present in the local repository (or for a SNAPSHOT, when the remote repository contains one that is newer). By default, Maven will download from the central repository.

5.2  配置远程资源库

<project>  
  ...  
  <repositories>  
    <repository>  
      <id>jboss</id>  
      <name>JBoss Repository</name>  
      <url>http://repository.jboss.com/maven2/</url>  
      <releases>  
        <enabled>true</enabled>  
      </releases>  
    </repository>  
    <snapshots>  
      <enabled>false</enabled>  
    </snapshots>  
    <layout>default</layout>  
  </repositories>  
  ...  
</project> 

在repositories元素下，可以使用repository子元素声明一个或者多个远程仓库。该例中声明了一个id为jboss，名称为JBoss Repository的仓库。任何一个仓库声明的id必须是唯一的，尤其需要注意的是，maven自带的中央仓库使用的id为central，如果其他的仓库声明也使用该id，就会覆盖中央仓库的配置。该配置中的url值指向了仓库的地址，一般来说，该地址都基于http协议，maven用户都可以在浏览器中打开仓库地址浏览构件。
该例配置中的releases和snapshots元素比较重要，它们用来控制Maven对于发布版构件和快照版构件的下载。该例中releases的enabled值为true，表示开启JBoss仓库的发布版本下载支持，而snapshots的enabled值为false，表示关闭JBoss仓库的快照版本的下载支持。该例中的layout元素值default表示仓库的布局是Maven2及Maven3的默认布局，而不是Maven1的布局。
对于releases和snapshots来说，除了enabled，它们还包含另外两个子元素updatePolicy和checksumPolicy:

<snapshots>  
  <enabled>true</enabled>  
  <updatePolicy>daily</updatePolicy>  
  <checksumPolicy>ignore</checksumPolicy>  
</snapshots>  

元素updatePolicy用来配置Maven从远程仓库检查更新的频率，默认的值是daily，表示Maven每天检查一次。其他可用的值包括：never---从不检查更新；always---每次构建都检查更新；interval:X---每隔X分钟检查一次更新(X为任意整数)。
元素checksumPolicy用来配置Maven检查检验和文件的策略。当构件被部署到Maven仓库中时，会同时部署对应的校验和文件。在下载构件的时候，Maven会验证校验和文件，如果校验和验证失败，怎么办？当checksumPolicy的值为默认的warn时，Maven会在执行构建时输出警告信息，其他可用的值包括：fail---Maven遇到校验和错误就让构建失败；ignore---使用Maven完全忽略校验和错误。

5.3 远程仓库的认证

大部分远程仓库无须认证就可以访问，但有时候出于安全方面的考虑，我们需要提认证信息才能访问一些远程仓库。例如，组织内部有一个Maven仓库服务器，该服务器为每个项目都提供独立的Maven仓库，为了防止非法的仓库访问，管理员为每个仓库提供了一组用户名级密码。这时，为了能让Maven访问仓库内容，就需要配置认证信息。
配置认证信息和配置仓库信息不同，仓库信息可以直接配置在POM文件中，但是认证信息必须配置在settings.xml文件中。这是因为POM往往是被提交到代码仓库中供所有成员访问的，而settings.xml一般只放在本机。因此，settings.xml中配置认证信息更为安全。假设需要为一个id为my-proj的仓库配置认证信息，编辑settings.xml文件见

settings>  
  ...  
  <servers>  
    <server>  
      <id>my-proj</id>  
      <username>repo-user</username>  
      <password>repo-pwd</password>  
    </server>  
  </servers>  
  ...  
</settings>  

5.4 部署至远程仓库

私服的一大作用是部署第三方构件，包括组织内部生成的构件以及一些无法从外部仓库直接获取的构件。无论是日常开发中生成的构件，还是正式版本发布的构件，都需要部署到仓库中，供其他团队成员使用。
Maven除了能对项目进行编译、测试、打包之外，还能将项目生成的构建部署到仓库中。首先，需要编辑项目的pom.xml文件。配置distributionManagement元素，见代码：

<project>  
  ...  
  <destributionManagement>  
    <repository>  
      <id>proj-releases</id>  
      <name>Proj Release Repository</name>  
      <url>http://192.168.1.100/content/repositories/proj-releases</url>  
    </repository>  
    <snapshotRepository>  
      <id>proj-snapshots</id>  
      <name>Proj Snapshot Repository</name>  
      <url>http://192.168.1.100/content/repositories/proj-snapshots</url>  
    </snapshotRepository>  
  </destributionManagement>  
  ...  
</project> 

distributionManagement包含repository和snapshotRepository子元素，前者表示发布版本构件的仓库，后者表示快照版本的仓库。这两个元素下都需要配置id、name和url，id为该远程仓库的唯一标识，name是为了方便人阅读，关键的url表示该仓库的地址。
往远程仓库部署构件的时候，往往需要认证。就是需要在settings.xml中创建一个server元素，其id与仓库的id匹配，并配置正确的认证信息。不论远程仓库下载构件，还是部署构件至远程仓库，当需要认证的时候，配置的方式是一样的。配置正确后，在命令行运行mvn clean deploy，Maven就会将项目构建输出的构件部署到配置对应的远程仓库，如果项目当前的版本是快照版本，则部署到快照版本仓库地址，否则就部署到发布版本仓库地址。  

6.maven依赖机制

在 Maven 依赖机制的帮助下自动下载所有必需的依赖库，并保持版本升级

7.定制库到maven本地资源库

使用IDE插件。MyEclipse集成了Maven4MyEclipse插件，支持定制库到Maven本地资源库的导入。
File->Import，搜索Maven。

8.创建maven工程 (https://my.oschina.net/xuqiang/blog/99854  更详细讲解,推荐看)

maven 工程类型:  
1,.jar 包工程(Java项目)     
2. war包工程(web项目)     
3. pom工程(聚合项目)

8.1  maven jar项目

8.1.1:选择 new→maven→Maven Project

8.1.2

8.1.3选择 maven-archetype-quickstart  //创建Java项目

8.1.4 输入项目信息

8.2 maven web项目

8.2.1 选择 new→maven→Maven Project

8.2.2

8.2.3 

8.2.4 输出项目信息

8.3 maven 聚合项目并添加子项目

8.3.1 创建Tman-parent 聚合项目

(结构图)

Tman-parent                -- 管理依赖 jar 包的版本，全局，公司级别(pom聚合项目)
|--Tman-common             -- 通用组件、工具类(jar项目)
|--Tman-manage             -- 后台系统(pom聚合项目)
|--com.Tman.manage.web     -- web项目(war项目)
|--com.Tman.manage.service -- service层(jar项目)
|--com.Tman.manage.mapper  -- mybatis的mapper(jar项目)
|--com.Tman.manage.pojo    -- pojo类(jar项目)

选择 new→maven→Maven Project(不使用maven骨架)

8.3.2

8.3.2 然后依次建立Tman-common工程 ,依赖Tman-parent 工程

8.3.2创建Tman-manage聚合工程

创建Tman-manage聚合工程下的子工程,

创建Tman-manage-web(war工程)

1.选Maven-Module

2.填写module name

3.选择项目类型(war项目)

9.maven 命令

9.1  mvn compile 命令 ,完成编译操作执行完毕后，会生成 target 目录，该目录中存放了编译后的字节码文件

9.2   mvn clean 命令 ,执行完毕后, 会将 target 目录删除。

9.3   mvn test 命令，完成单元测试操作

9.4  mvn package 命令，完成打包操作, 会在 target 目录中生成一个文件，该文件可能是 jar、war

9.5  mvn install 命令，完成将打好的 jar 包安装到本地仓库的操作执行完毕后，会在本地仓库中出现安装后的 jar 包，方便其他工程引用

9.6   cmd 中录入 mvn clean compile 命令组合指令，先执行 clean，再执行 compile，通常应用于上线前执行，清除测试类.

9.7  cmd 中录入 mvn clean test 命令组合指令，先执行 clean，再执行 test，通常应用于测试环节.

9.8  cmd 中录入 mvn clean package 命令组合指令，先执行 clean，再执行 package，将项目打包，通常应用于发布前

执行过程：
清理————清空环境
编译————编译源码
测试————测试源码
打包————将编译的非测试类打包

9.9   cmd 中录入 mvn clean install 查看仓库，当前项目被发布到仓库中组合指令，先执行 clean，再执行 install，将项目打包，通常应用于发布前

执行过程：
清理————清空环境
编译————编译源码
测试————测试源码
传智播客 Java 学院 传智.关云长
打包————将编译的非测试类打包
部署————将打好的包发布到资源仓库中

10. maven 核心概念

groupId：定义当前 Maven 组织名称
artifactId：定义实际项目名称
version：定义当前项目的当前版本

10.1. maven 依赖管理

就是对项目中 jar 包的管理。可以在 pom 文件中定义 jar 包的 GAV 坐标，管理依赖。依赖声明主要包含如下元素：

<dependencies>
     <dependency>
          <groupId>junit</groupId>
          <artifactId>junit</artifactId>
          <version>4.10</version>
          <scope>test</scope>
     </dependency>
</dependencies>

10.2  maven依赖范围

其中依赖范围 scope 用来控制依赖和编译，测试，运行的 classpath 的关系. 主要的是三种依赖关系如下：

1.compile： 默认编译依赖范围。对于编译，测试，运行三种 classpath 都有效
2.test：测试依赖范围。只对于测试 classpath 有效
3.provided：已提供依赖范围。对于编译，测试的 classpath 都有效，但对于运行无效。因为由容器已经提供，例如 servlet-api
4.runtime:运行时提供。例如:jdbc 驱动

10.3 依赖传递

10.3.1 直接依赖和间接依赖

如果 B 中使用 A，C 中使用 B，则称 B 是 C 的 直接依赖，而称 A 是 C 的 间接依赖。
C->B     B->A
C 直接依赖 B
C 间接依赖 A

10.3.2  依赖范围对传递依赖的影响

左边第一列表示第一直接依赖范围
上面第一行表示第二直接依赖范围
中间的交叉单元格表示传递性依赖范围。
总结：

   当第二依赖的范围是 compile 的时候，传递性依赖的范围与第一直接依赖的范围一致。
   当第二直接依赖的范围是 test 的时候，依赖不会得以传递。 
   当第二依赖的范围是 provided 的时候，只传递第一直接依赖范围也为 provided 的依赖，且传递性依赖的范围同样为 provided；
   当第二直接依赖的范围是 runtime 的时候，传递性依赖的范围与第一直接依赖的范围一致，但 compile 例外，此时传递的依赖范围为 runtime；

10.3.2 依赖冲突

如果直接与间接依赖中包含有同一个坐标不同版本的资源依赖，以直接依赖的版本为准.

如果直接依赖中包含有同一个坐标不同版本的资源依赖，以配置顺序下方的版本为准.

推荐:   http://blog.csdn.net/u013755987/article/details/53088829