maven的基础入门

Maven是Java世界中一个很好使的项目管理工具，关于【好使】这个特性从项目的使用量上就能体现出来，虽然说现在有更好使的Gradle，但是Maven的地位也不会那么轻易被撼动，支持者还是多多。

Maven的产生背景

在学习一个新知识之前，应该要以历史的眼光来看待这个技术出现的原因，以及这个技术解决的问题，也就是背景，这样能更好地理解这个技术。

在没有Maven之前，开发一个项目，当需要用到别人写的代码的时候，基本上是这样的：

1.开发一个项目，当需要用到别人写好的jar包，就需要把开源的jar包下载下来放到项目的lib目录下，并且根据这个目录添加到CLASSPATH中，以此来告诉Java执行环境，在哪些目录下可以找到要执行的Java程序需要的类或者包。

2.当下载了aa.jar包之后，发现还需要依赖bb.jar包，于是就去下载bb.jar包，重复步骤直到下载并添加完所有需要的jar包。

3.如果运气好，项目在添加完所有的依赖之后就能够正常运行了。但是如果运气差的话，就会遇到版本的问题，比如aa.jar包在调用bb.jar包的时候发现bb.jar包中根本没有需要的方法，这个方法只存在在bb.jar包别的版本中，那么这样的话，就需要花不少的时间在查找依赖和适配版本的jar包上了。

4.另外的，往git或者svn上提交代码的时候，还必须要把这些lib都上传上去，否则别人就要重复你前面做过的所有查找和添加依赖的操作。同样的，别人下载你的代码也是要把完整的lib下载下来。这样，不仅会浪费代码版本管理的时间，代码版本管理的空间，还会提高的开发的时间成本和降低开发的效率。

这时候Maven作为Java世界中的包管理工具就应运而生。就好像Linux世界中的yum、Web前端世界中的webpack一样，是一种方便开发者管理各种依赖的包管理工具。

Maven仓库的种类

Maven查找jar包的过程是这样的：先在本地仓库找；找不到的话，就去私服找（如果配置了私服的话）；再找不到，就到中央仓库去找（默认的中央仓库是http://repo1.maven.org/maven2/，由Maven团队负责维护）。

最后如果在中央仓库找到之后，就会在私服和本地仓库都放一份，从私服找到之后也会在本地仓库放一份，这样下次再查找依赖就不需要到中央仓库去下载了。

关于仓库的配置，当你安装（Windows下一般是解压和配置环境变量）好了Maven之后，Maven的安装目录在conf目录下会有一个settings.xml配置文件，这个配置文件中提供了很多的配置项，其中就有配置仓库的配置项，包括本地仓库、私服和中央仓库的配置。

关于私服首先要搭建私服，比较繁琐，需要用另外的篇幅来记录，因此这里就略过私服的配置，只提及本地仓库和中央仓库的配置。

本地仓库的配置是通过localRepository标签配置的：

<!-- localRepository
   | The path to the local repository maven will use to store artifacts.
   |
   | Default: ${user.home}/.m2/repository  -->
<localRepository>D:\maven_repo</localRepository>

中央仓库的配置是通过mirrors-mirror标签配置的（这里设置为淘宝镜像）：

<mirrors>
　　<!-- mirror
 　　| Specifies a repository mirror site to use instead of a given repository. The repository that
 　　| this mirror serves has an ID that matches the mirrorOf element of this mirror. IDs are used
 　　| for inheritance and direct lookup purposes, and must be unique across the set of mirrors.
 　　|
　　<mirror>
　　  <id>mirrorId</id>
　　  <mirrorOf>repositoryId</mirrorOf>
　　  <name>Human Readable Name for this Mirror.</name>
 　　 <url>http://my.repository.com/repo/path</url>
　　</mirror>
 　　-->
　　<mirror>
    　　<id>nexus-aliyun</id>  
    　　<mirrorOf>central</mirrorOf>    
    　　<name>Nexus aliyun</name>  
    　　<url>http://maven.aliyun.com/nexus/content/groups/public</url>  
　　</mirror>
</mirrors>

需要注意的是，这些配置项如果不进行配置的话，Maven是提供有默认值的，默认值都在注释掉的配置项中。

在自身的属性配置这一点上，Maven都贯彻了【约定优于配置】的理念，真的是优秀啊。

Maven项目的整体结构

Maven遵循的原则是【约定优于配置】，因此使用Maven构建的项目的默认结构是下图这样的：

1.Maven默认配置了${project.basedir}/src/main/java为项目的源代码目录。
2.Maven默认配置了${project.basedir}/src/main/test为项目的测试代码目录。
3.Maven默认配置了${project.basedir}/target为项目的编译输出目录等。

。。。

当然了，既然说是默认配置，当然是可以修改的，可以在项目的pom.xml的build标签中修改这些源代码目录，只是一般不建议改，一般人也不会去改。

<build>  
    <sourceDirectory>src/java</sourceDirectory>  
    <testSourceDirectory>src/test</testSourceDirectory>  
    <outputDirectory>output/classes</outputDirectory>  
    <testOutputDirectory>output/test-classes</testOutputDirectory>  
    <directory>target/jar</directory>  
</build>

Maven项目结构的特殊性是由【约定优于配置】的特性来决定的，这一特性减少了很多不必要的配置，是使之打败前辈Ant的主要原因之一。

Maven管理工具的目录结构

下图是Maven管理工具的目录结构。

bin目录：该目录包含了mvn运行的脚本，这些脚本用来配置Java命令，准备好CLASSPATH和相关的Java系统属性，然后执行Java命令。

boot目录：该目录只包含一个文件，该文件为plexus-classworlds-2.5.2.jar。plexus-classworlds是一个类加载器框架，相对于默认的Java类加载器，它提供了更加丰富的语法以方便配置，Maven使用该框架加载自己的类库。

conf目录：该目录包含了一个非常重要的文件settings.xml。直接修改该文件，就能在机器上全局地定制Maven的行为，即对所有用户都生效。一般情况下，我们更偏向于复制该文件至~/.m2/目录下，然后修改该文件，在用户级别定制Maven的行为。

lib目录：该目录包含了所有Maven运行时需要的Java类库，Maven本身是分模块开发的，因此用户能看到诸如maven-core-3.0.jar、maven-model-3.0.jar之类的文件，此外这里还包含一些Maven用到的第三方依赖如commons-cli-1.2.jar、commons-lang-2.6.jar等等。

settings.xml配置文件

这里详细说一下settings.xml这个文件，这个文件用于定制Maven的行为。上面已经说到settings.xml可以放在2个位置，一个是【~/.m2/setting.xml】（默认没有，需要我们自己复制），一个是【${maven.home}/conf/setting.xml】。这2个位置的配置文件的加载顺序为【~/.m2/setting.xml】>【${maven.home}/conf/setting.xml】，为了不影响他人，所以我们将conf下的settings.xml复制到用户目录，在用户级别定制Maven的行为。

这个和系统配置环境变量有点类似，Windos和Linux都可以配置系统级别的环境变量和用户级别的环境变量，用户级别的环境变量会覆盖系统级别的环境变量。

Maven的一些常用命令

要使用Maven当然要会一些常用的命令，不然都不叫会使用Maven。

命令	描述
mvn -version	显示版本信息
mvn clean	删除target目录
mvn compile	编译src/main/java下的源代码
mvn package	打包，在target下生成jar包或者war包
mvn test	执行src/test/java下以Test开头或者以Test结尾的类的测试用例
mvn install	打包，并把jar包或者war包复制到本地仓库，供其他模块使用
mvn deploy	将打包的文件发布到私服
mvn dependency:tree	打印出项目的整个依赖树

当然也可以将命令连着使用，比如使用【mvn clean package】清理打包；比如使用【mvn clean package -DskipTests=true】清理打包，并跳过测试用例；比如使用【mvn clean install】清理打包，并将jar包或者war包复制到本地仓库。

更多的，也可以配合将结果输出到文件来方便查看，比如【mvn dependency:tree > dependency.txt】。

pom.xml中的<dependency>标签

<dependency>标签中一般是包含<groupId>、<artifactId>和<version>三个子标签。

<groupId>表示公司域名倒过来，<artifactId>表示功能的命名，<version>表示版本号，这三个维度就确定了一个jar包，就像用(x, y, z)坐标在三维空间中确定一个唯一的点一样。

另外的，<dependency>标签中还可以包含<scope>标签，表示此依赖包的作用范围，下面列出一个<scope>参数候选值的表格。

参数	解释	是否会被打入最终的jar包
compile	默认的scope（不指定）	是
test	测试使用	否
provided	编译需要	否
runtime	编译不需要，运行时需要（接口与实现分离）	是
system	加载本地jar（很少使用）	否

 

"长得丑的水果，都会努力让自己甜一点。"