Maven On Road

最新推荐文章于 2024-09-21 11:17:33 发布

柔软的海带精

最新推荐文章于 2024-09-21 11:17:33 发布

阅读量964

点赞数

分类专栏： Maven 文章标签： maven reference merge jar 脚本 ant

本文链接：https://blog.csdn.net/lanjie911/article/details/7724673

版权

Maven 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

maven简述

首先简单说下为什么用maven，以及maven是怎么来的。

最早apache的Jakarta Turbine项目组开发项目的时候，发现该项目有很多子项目，引用的依赖jar包和编译ant脚本写法如出一格，几乎没有任何区别。更进一步发现，同样的工程存在类似的问题。就想弄出一个简单的，统一的，便准的构建过程和工具，让大家的工程遵循统一的构建标准。

为什么要定这个标准呢，可以知道，不同的工程经常互相依赖。比如A\B\C，A依赖于B，A也依赖于C，同时B也依赖于C。麻烦就麻烦在A\B依赖于C的版本是不同的，当引入B时，就会出现问题。举个具体的例子：

A依赖于工程B，依赖于common-logging.1.4.3.jar

B工程依赖于common-logging.1.4.5.jar

当把B工程（jar）引入A工程时，在编译时没有问题，但是一旦运行就会出现class version error。

同理，A工程和B工程的发布过程往往一样，但是两个工程都维护了一套相同的ant脚本。

Maven由此诞生。主要解决了

同样的类库共享依赖
类库新版本更新时，依赖通知
统一的构建过程
标准化的发布流程

maven的安装和设定

下载最新maven版本的zip包，然后解压缩。按照如下方法设定：

设定了maven安装目录下的conf/settings.xml之后，别忘记设定~/.m2/settings.xml（切记如果没有，就拷贝过去一个），这个设置是优于conf/settings.xml。

奇怪的是maven是两个配置文件merge使用的。一直不明白所谓的merge到底是为了什么。都不知道谁的配置优先级别更高。

至少从设定offline元素的值来看。~/.m2/settings.xml的优先级别更高。

maven安装完毕（其实就是将zip包解压到指定目录，然后配置MAVEN_HOME、M2和JAVA_HOME等环境变量，最后将M2放置到系统的path路径环境变量中的过程。

看maven的reference，使用mvn archetype:generate并不是一定能成功，因为安装了maven能运行，但是maven目前为止任何插件都没有安装（这里必须了解maven的思想，maven的所有的动作，包括clean、build等，通通都是通过插件完成的，maven安装完毕后只是一个运行框架的壳子，根本不能做任何具体的事情），所以mvn archetype:generate命令一定是执行失败，报如下异常：

The POM for org.apache.maven.plugins:maven-clean-plugin:jar:2.4.1 is missing, no dependency information available

在apache maven工程首页上http://maven.apache.org/plugins/index.html ，maven开发团队自己也说：

Maven is - at its heart - a plugin execution framework; all work is done by plugins.

Maven说到底就是个插件执行框架，所有的工作都是插件做的。

生命周期、阶段和目标

Maven执行的顺序被称为生命周期。Maven有默认的三个生命周期clean，default和site。每个生命周期都是由不同的“阶段”组成的。这些阶段中，有的阶段的名字就是生命周期的名字。

比如clean生命周期，包含三个阶段pre-clean、clean和post-clean。

比如site生命周期，包含四个阶段pre-site、site、post-site和site-deploy。

Maven觉得光定义阶段粒度还不够细，又加入了晦涩难懂的概念“目标（goal）”，至今未发现有哪篇文章或者网站能把为什么这么做（意义）及“目标”和“阶段”的关系彻底说明白的。

所以我这里尝试说明下为什么变态的maven开发团队要这么做。

首先，阶段是定义死的，执行一个阶段（phase），会将这个阶段之前的所有的阶段都按照顺序执行一遍。我猜测当时maven团队认为这是个标准的做法，但是后来在实践中发现不按照顺序进行构建的工程还是居多，如果不加入能随意执行的（不触发额外动作执行的功能，调用“阶段”会触发“额外的阶段”执行。）“东西”是不行的。

其次，阶段更像是“逻辑上”的“业务包装”，而目标则是一个方法或者手段（方式），明显在很多场合下，使用较小粒度的目标更能够解决实际问题。

第三，maven设计者，将目标和阶段进行绑定，没有目标的阶段将不被执行，绑定阶段的目标，在执行各个阶段的时候，该目标被反复执行。（可以想象一下Java中的利用反射的方法，将Method对象在不同的Object实例上调用），这种构成方式是极为灵活的。

因此，变态的maven开发团队就做成了这个样子。（其实就是事先没想清楚的后果，这种设计虽然灵活，但是从业务逻辑上讲，非常混乱，就连maven doc都不能清楚的说明这之间的关系）