Maven一些总结

 1.Maven的安装和配置

  从Maven的官网上下载Maven的安装包，http://maven.apache.org/download.html。

  将其解压在你想安放的目录下。

  然后配置Maven的环境变量（M2_HOME），比如说我的Maven安装在D:\Maven\apache-maven-3.0.3下，那么M2_HOME=D:\Maven\apache-maven-3.0.3。如果想在任何目录下使用maven命令，就将M2_HOME目录下的bin目录加入到加入到系统环境变量Path中。

  使用mvn -v 就可以看到当前maven的版本信息，表明安装成功。

  注：安装maven前必须确定自己的电脑已经安装了JDK，并且java环境已经配置好了。

2.设置HTTP代理

  有些时候处于安全考虑，自己的主机不能直接访问外网的中央仓库，而是指定一个经过安全认证的代理服务器，通过该代理服务器来访问中央仓库。

  如何配置HTTP代理？

  首先在安装了Maven后，M2_HOME/conf目录下放置了Maven的配置信息（setting.xml），我们可以通过修改该文件来设置代理。但是，如果直接在该文件上修改，那么影响将是全局的，而且不利于以后的升级。所以我们将该文件复制一份，放到~/.m2下，那么该文件将会覆盖M2_HOME/conf下的setting.xml，而且只对当前用户有效。这样每个用户都可以根据自己的喜好和需求来配置适合自己的Maven。具体如何在setting.xml中配置HTTP代理，代码入下：

  <proxies>

       <proxy>

       <id>my-proxy</id>

       <active>true</active>

       <protocol>http</protocol>

       <host>...</host>

       <port>...</port>

       <useranme>...</useranme>

       <password>...</password>

       <nonProxyHosts>...</nonProxyHosts>

       </proxy>

  </proxies>

  <active>的值为true,表示该代理被激活，<protocol>表示代理协议，当然是http了，<host>表示代理的主机地址，<port>代表代理主机的端口，<useranme>，<password>

  用来进行安全认证， <nonProxyHosts>代表哪些主机不需要进行代理。

  注：当在做项目使用Maven的时候，必定要下载很多jar包和插件放在本地的仓库中，安装好Mavaen后，本地仓库会有一个默认的存放位置。当然也可以通过配置setting.xml文件来改变。比如我自己的配置，将仓库放在D:/dev/repository下：

  <localRepository>D:/dev/repository</localRepository>

3.pom文件编写的一些细节

  ①在编写pom文件的时候，相同的版本号或其他一些字符串会重复出现，那么我们可以将重复的字符串抽取出来，进行定义，然后在需要使用的地方进行引用。如下：

  <properties>

       <springframework.version>2.5.6</springframework.version>

  </properties>

  .....

  <dependency>

      <groupId>...</groupId>

      <artifactId>...</artifactId>

      <version>${springframework.version}</version>

  </dependency>

  ....

4.聊聊Maven的仓库机制

  我们不必每做一个项目就将其所依赖的jar包和插件都引入到项目中，我们可以定义依赖，指定在仓库中的位置。仓库包含了很多的插件和jar包，分为本地仓库和远程仓库，当定义一个依赖的时候，系统会首先根据坐标在本地仓库中寻找jar包，如果本地仓库中有所需要的jar包和插件，那么就不会去访问远程仓库，如果没有就会去访问远程仓库，并且把相应的jar包和插件下载到本地仓库中去。

  注：安装好Maven以后，如果不执行任何Maven命令，本地仓库目录是不存在的，当用户输入第一条Maven命令之后，Maven才会创建本地仓库。

  Maven安装好后，会有一个默认的远程仓库，即中央仓库，配置信息写在Maven的超级POM文件中。当然除了中央仓库，还可以配置其他远程仓库。即当在中央仓库中找不到jar包的时候回去其他远程仓库中寻找。配置代码如下：

  <repositories>  

      <repository>  

        <id>public</id>  

        <url>http://192.168.1.20:8081/nexus/content/groups/public/</url>;  

        <releases>  

          <enabled>true</enabled>  

        </releases>  

        <snapshots>  

          <enabled>true</enabled>  

        </snapshots>  

      </repository>

      </repositories> 

 

 在组织内部，有一个Maven仓库服务器，该服务器为每个项目都提供独立的Maven仓库，为了防止非法的仓库访问，管理员为每个仓库提供了一组用户名和密码。为了能让Maven访问仓库内容，就需要配置认证信息。配置代码如下：

 <server>

      <id>releases</id>

      <username>deployment</username>

      <password>deployment123</password>

  </server>

  仓库的镜像

如果仓库X可以提供仓库Y存储的所有内容，那么就可以认为X是Y的一个镜像。换句话说，任何可以从Y获得的构件，都能从它的镜像中获取。

<mirrors>

   <mirror>

      <id>mirrorId</id>

      <mirrorOf>central</mirrorOf>

      <name>Human Readable Name for this Mirror.</name>

      <url>http://my.repository.com/repo/path</url>;

    </mirror>

</mirrors>

上述代码配置了一个中央仓库的镜像仓库mirrorId。其他配置项与一个普通仓库是相同的。

5.生命周期和插件

  在有关Maven的日常应用中，命令行的输入往往就对用了生命周期，如mvn package就表示执行生命周期阶段package。

  Maven有三套生命周期，clean,default,site.

  三套生命周期是相互独立的，用户可以仅仅调用生命周期的某一个阶段，而不会对其他周期产生影响。

每个生命周期包含一些阶段，并且这些阶段是有顺序的，后面的阶段依赖前面的阶段。以clean生命周期为例，它有三个阶段，pre-clean,clean,post-clean。当用户调用pre-clean的时候，只有pre-clean阶段执行，当用户调用clean的时候，那么就会执行
pre-clean，clean这两个阶段。

从命令行执行maven任务的主要方式就是调用maven的生命周期阶段：
$mvn clean：该命令调用clean生命周期的clean阶段。实际指向的阶段为clean生命周期的pre-clean和clean阶段。
插件绑定：
Maven的生命周期与插件相互绑定，用以完成实际的构建任务。具体而言，是生命周期的阶段与插件的目标相互绑定，以完成某个具体的构建任务。例如项目编译这一项任务，它对应了default生命周期的compile阶段，而maven-compiler-plugin这一插件的compile目标能完成该任务。因此，将他们绑定，就能实现项目编译的目的。
内置绑定：为了能让用户几乎不用任何配置就能构建maven项目，maven在核心为一些主要的生命周期绑定了很多插件和目标，当用户通过命令行调用生命周期阶段的时候，对应的插件目标就会执行相应的任务。
自定义绑定：
<build>
<plugins>
<plugin>
<groupId>...</groupId>
<artifactId>...</artifactId>
<version>...</version>
<!--executions标签内配置插件可在哪些阶段运行-->
<executions>
<!--一个execution标签代表一个具体的阶段-->
<execution>
<id></id>
<!--phase标签指明具体阶段的名称，如果没有填写这个标签，那么目标就会绑定到默认的生命周期阶段-->
<phase></phase>
<goals>
<!--绑定在这个阶段的具体的插件目标-->
<goal></goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
当然还可以在插件的配置中添加<configuration>,用来配置插件的配置信息。（可以全局配置插件，也可以局部配置插件，就是根据configuration书写的位置来判断）
如果多个目标绑定到同一个生命周期阶段，那么多个目标执行的先后顺序将是它们声明的先后顺序。